ANCP Next Steps

+=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: Michel.Platnic@ecitele.com=20 [mailto:Michel.Platnic@ecitele.com]
Sent: 24 May 2006=20 11:46
To: Sanjay Wadhwa
Cc: = l2cp@ietf.org
Subject:=20 RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation

Hi Sanjay and all,
I support Sanjay's proposal to have this encapsulation = transported by=20 ANCP, even if we may argue that
we=20 already have 2 protocols that may transport this information (DHCP and=20 PPPoE).
About having a = different TLV to=20 transport the Encapsulation, it only partially solves the problem of = potentially=20 mixing
layer 1 and layer 2 = information.=20 Actually the DSL forum (TR-101) uses same principle described in your = document=20 to transport this
information, it is=20 probably wise to follow the same mechanism..
Unless other people share this concern, I'll go with your=20 proposal.
Best = Regards,
Michel.

"Sanjay = Wadhwa"=20 <swadhwa@juniper.net>

24/05/2006 00:01

To	<stefaan.de_cnodder@alcatel.be>=20
cc	l2cp@ietf.org=20
Subject	RE: [L2CP] RE: Wadhwa new = draft 01-=20 Encapsulation + Remode Id = comments

>-----Original Message----- >From:=20 stefaan.de_cnodder@alcatel.be >[mailto:stefaan.de_cnodder@alcatel.b= e] >Sent:=20 Tuesday, May 23, 2006 1:07 PM >To: Sanjay Wadhwa >Cc:=20 l2cp@ietf.org >Subject: Re: [L2CP] RE: Wadhwa new draft 01- = Encapsulation=20 + Remode Id >comments > > > >Hi=20 Sanjay, > >> >> - Why was the = access loop=20 encapsulation object included within a >> message = where=20 all parameters transmitted are layer 1 oriented? >> = There=20 might be several encapsulations available per >physical link,=20 a >> new message could maybe better serve the = purpose=20 of >> transmitting the encapsulation=20 parameters. >> [[SW]] I have sympathy for your = arguement=20 as I had a similar >> concern, which is why L2 = encaps has=20 been specified as a >seprate and >> = optional TLV=20 (although same message). >> It is to an extent = useful for=20 the BNG to learn l2 encaps on the >> local-loop = as it can=20 in some cases allow for more >accurate shaping >> = =20 of subscriber traffic. >> > >Why not specifying = the=20 bandwidth at L2? Then the BNG just takes this >bandwidth for = shaping and=20 it does not have to take care of what >encapsulation has been = used. Why=20 bottering the BNG with the >encap on the >DSL line. And = what if=20 later someone wants to do the same on non-DSL >access lines? Are = we going=20 to add encap types and updating the >BNG with >these new = encap=20 types to compute the correct shaping rate? I >believe it = >would be=20 better to specify the bandwidth at which the BNG has to = shape. [SW]=20 Shaping on the BNG (based on counting bytes transmitted) needs = to know the=20 "byte adjustment" (under/over-head) due to difference in encaps on = the=20 aggregation network and access loop. I suppose the access-node could = indicate=20 the absolute difference in terms of bytes between the = two encapsulations..=20 however, this might not be accurate as an aggregation switch upstream = of the=20 DSLAM could change the encaps (e.g. insert an outer VLAN tag). = Ideally, the=20 BNG needs to use the difference between it's encaps and the encaps on = the=20 local-loop. Also, the BNG needs to adjust for cell-tax if the = local-loop is=20 cell=20 based. -Sanjay >regards, >Stefaan > &= gt; >>=20 *Chapter 5.4.2* >> - = Typo: >>=20 Type (Access-Loop-Circuit-ID =3D 0x01) : defined in = section=20 5.4.1 >> Type = (Access-Aggregation-Circuit-ID-Binary =3D=20 0x02): defined in >> section 5.4.1. = =20 >> Type = (Access-Aggregation-Circuit-ID-ASCII =3D=20 0x03) : defined in >> section 5.4.1. = >>=20 These lines should be updated to comply to Chapter=20 5.4.1. >> >> [[SW]] Will = fix. >>=20 >> Thanks >> = =20 -Sanjay >> >> Thanks and Best=20 Regards, >> Michel. >> >> = >>=20 >> >> *"Sanjay Wadhwa"=20 <swadhwa@juniper.net>* >> >> = 05/04/2006=20 19:22 >> >> = =20 >> To >> = =20 =20 "Busschbach, Peter B \(Peter\)" = ><busschbach@lucent.com>,=20 "Wojciech >> Dec \(wdec\)" = <wdec@cisco.com>,=20 <l2cp@ietf.org> >> cc >> = =20 = >>=20 Subject >> = =20 RE: [L2CP] Advantages of L2CP (was: = Revised WG=20 Charter Draft) >> >> >> = =20 >> = >>=20 >> >> >> >> =20 Peter >> Please see inline.. >>=20 >> >-----Original = Message----- >>=20 >From: Busschbach, Peter B (Peter)=20 >[mailto:busschbach@lucent.com] >> = >Sent:=20 Wednesday, April 05, 2006 10:51 AM >> = >To:=20 'Wojciech Dec (wdec)'; l2cp@ietf.org >> =20 >Subject: [L2CP] Advantages of L2CP (was: Revised WG = >Charter=20 Draft) >> > >> =20 > >> >Hi Woj, >> = =20 > >> >To address the second = half of our=20 email exchange: >> > >> = =20 >I did notice the sentence that addressed Dave's = concern. >>=20 >However, my point was that the charter claims = that L2CP=20 will >> >have a specific benefit = ("avoiding=20 complex cross-organization >> = >interactions"),=20 while it is far from clear that in this >> =20 >respect L2CP is any better than other solutions. >>=20 >> [Sanjay] All that the charter is saying is = that L2C=20 work >will undertake >> use-cases that aim = to=20 simplify service management by >avoiding complex >> = =20 cross-organization interactions. It is a nobel goal that = >L2C is=20 striving >> to achieve.. What is wrong with that = ? This=20 is >irrespective of wether >> other = solutions can=20 provide this or not. >> So, as an example, = charter for a=20 new dynamic routing >protocol might say >> = that it=20 will strive to achieve fast network-wide >convergence (which is=20 a >> clear benefit over static routing). But, = obviously=20 it is >ok for multiple >> dynamic routing=20 protocols to work towards this goal and have this >> = =20 explicitly stated in their charter. >> >> = =20 -Sanjay >> >> >> >I = believe=20 that the charter should avoid stating benefits that >> = =20 >are debatable and therefore suggest that the text that = I >>=20 >quoted in my first email be deleted from the=20 charter. >> > >> =20 >Peter >> > >> = =20 >> -----Original Message----- >> =20 >> From: Wojciech Dec (wdec) = [mailto:wdec@cisco.com] >>=20 >> Sent: Wednesday, April 05, 2006 7:34 = AM >>=20 >> To: Busschbach, Peter B (Peter);=20 l2cp@ietf.org >> >> Subject: RE: = [L2CP] Re:=20 Revised WG Charter Draft >> = >> >>=20 >> >> >> Hi = Peter, >> >> >> = =20 >> To address 1) we have put in the following statement = >in=20 the charter >> >> which you may have = not=20 noticed. >> >> >> = =20 >> "The protocol design will not preclude other uses of=20 L2CP." >> >> >> = =20 >> WRT 2) we do not lay any claims to how different=20 >operators structure >> >> = their data=20 bases, and some are probably better at doing it >> = =20 >> than others. >> >> = However it=20 does seem to be a fairly common problem that the >> = =20 >> info related >> >> to = a single=20 subscriber's network service needs to be farmed >> = =20 >> out and fed >> >> into = numerous custom built manager systems besides also the >> = =20 >Radius DB. >> >> The idea = is to=20 allow a mechanism, through the use of L2CP, >> =20 >to have the >> >> Access = node be=20 provided with such information as and when >> =20 >> needed by the >> >> = NAS which=20 in turn accesses a common repository like >a Radius = DB. >>=20 >> Dave's statement was, I believe, in = relation to=20 different >> >> subject; = that >>=20 >> of a wholesale-retail operation, where = indeed=20 the >> >relationship is more >> = =20 >> complex. However we do plan on addressing this as=20 >evidenced by the >> >> = statement in=20 the charter: >> >> "L2CP will address = security aspects of the control protocol, >> =20 >including >> >> the trust = model=20 between NAS nodes and access nodes." >> =20 >> >> >> = Regards, >>=20 >> Woj. >> =20 >> >> >> -----Original=20 Message----- >> >> From: Busschbach, = Peter B=20 (Peter) >[mailto:busschbach@lucent.com] >> = >> Sent: 04 April 2006 21:23 >> =20 >> To: 'l2cp@ietf.org' >> = >>=20 Subject: [L2CP] Re: Revised WG Charter Draft >> =20 >> >> >> I have two = comments on=20 the revised charter. >> = >> >> =20 >> 1) = =20 At the end of the BOF, Mark >Townsley limited >> = =20 the scope of the >> >> working group. = Unfortunately, this is not captured very >> =20 >clearly in the >> >> = meeting=20 minutes. The critical sentence in the >meeting minutes = is >>=20 "DSL >> >> but good = engineers=20 ...". I.e. the focus of the WG is >to solve a >> = =20 >> particular issue in DSL access networks, but as = good >>=20 >> engineers we should >> = =20 >> not preclude the use of the protocol for other=20 applications. >> >> >> = =20 >> I don't see the limited scope reflected in the new=20 charter. >> >> >> = =20 >> 2) = Under=20 "Line Configuration". the >charter says: >> = =20 >> >> >> > L2CP is = intended to=20 simplify the OSS >infrastructure for service >> = =20 >> > management, allowing subscriber-related service data = to=20 be >> >> maintained >> = =20 >> > in fewer repositories (e.g. RADIUS server back-end=20 >database) >> while >> = =20 >> > avoiding complex cross-organization=20 interactions. >> >> >> = =20 >> I don't understand how L2CP leads to fewer Radius=20 server >> >back end data >> = =20 >> bases. I also don't understand how L2CP avoids=20 >cross-organizational >> >>=20 interactions. There seems to be an assumption that it is ok >> = =20 >> for L2CP to >> = >> cross=20 organizational boundaries but not for other >protocols. I=20 don't >> >> think that is correct. At = the=20 BOF, Dave Allan pointed out >> = >> that=20 this is >> >> one of the more = difficult=20 problems to solve. Therefore, I >> = >believe=20 that >> >> this text should be = removed from=20 the charter. >> >> >> = =20 >> Peter >> = >> >> =20 >> >> = >> >>=20 >>=20 _______________________________________________ >> = =20 >> L2cp mailing list >> = >>=20 L2cp@ietf.org >> >>=20 https://www1.ietf.org/mailman/listinfo/l2cp >> =20 >> >> > >> = =20 >_______________________________________________ >> = =20 >L2cp mailing list >> =20 >L2cp@ietf.org >> =20 >https://www1.ietf.org/mailman/listinfo/l2cp >> = =20 > >> >> =20 _______________________________________________ >> = L2cp=20 mailing list >> L2cp@ietf.org >> = =20 https://www1.ietf.org/mailman/listinfo/l2cp >> >>=20 >>=20 >--------------------------------------------------------------->--------- >>=20 >> _______________________________________________ >> = L2cp=20 mailing list >> L2cp@ietf.org >>=20 https://www1.ietf.org/mailman/listinfo/l2cp > ______________= _________________________________ L2cp=20 mailing=20 list L2cp@ietf.org https://www1.ietf.org/mailman/listinfo/l2cp <= /TT> ------_=_NextPart_001_01C67F1F.5AA142AD-- --===============1544132435== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ L2cp mailing list L2cp@ietf.org https://www1.ietf.org/mailman/listinfo/l2cp --===============1544132435==-- From l2cp-bounces@ietf.org Wed May 24 07:29:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FirY2-0007Ro-SH; Wed, 24 May 2006 07:29:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FirY2-0007Rj-5d for l2CP@ietf.org; Wed, 24 May 2006 07:29:06 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FirY0-0000lA-M2 for l2CP@ietf.org; Wed, 24 May 2006 07:29:06 -0400 Received: from gbmail02.netfr.alcatel.fr (gbmail02.netfr.alcatel.fr [155.132.251.26]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k4OBT10H005952 for ; Wed, 24 May 2006 13:29:01 +0200 In-Reply-To: <4472DFA7.40609@alcatel.be> Subject: Re: [L2CP] Updated LC charter To: Stefaan De Cnodder X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Matthew.Bocci@alcatel.co.uk Date: Wed, 24 May 2006 12:23:39 +0100 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 05/24/2006 12:29:01 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: l2CP@ietf.org X-BeenThere: l2cp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Layer 2 Control Protocol Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: l2cp-bounces@ietf.org Stefaan, On further investigation, it seems that RFC2881 describes a NAS in detail. This appears to coincide with what the DSLF would term a BNG or BRAS. To keep with current IETF terminology, I suggest we continue to use NAS, but add a reference to RFC2881 for the detailed NAS definition. Best regards, Matthew Stefaan DE CNODDER/BE/ALCATE L@ALCATEL To Matthew BOCCI/GB/ALCATEL@ALCATEL 23/05/2006 11:10 cc l2CP@ietf.org Subject Re: [L2CP] Updated LC charter Matthew, > > Network Access Server (NAS) - Network device which aggregates > multiplexedSubscriber traffic from a number of Access Nodes. The NAS > plays a central role in per-subsciber policy enforcement and QoS. Often > referred to as an Broadband Network Gateway (BNG) or Broadband Remote > Access Server (BRAS). > > [Stefaan] RFC2138 already define the term NAS. Is it the same > definition? Is it needed to repeat it, if not the same then better to > use another term. > > MB> Unfortunately they do not seem to be exactly the same, since the RFC > assumes a RADIUS client in the NAS. Do you have any other suggestions? > Could we just go with BNG, as per the DSL Forum? > BNG looks fine for me, and remove NAS to avoid confusion. > > 3. Remote Connectivity Test > Traditional DSL access and aggregation networks employ point-to-point > ATM circuits between the AN and NAS for each subscriber, allowing > troubleshooting of the local loop from the NAS via end-to-end ATM > loopbacks. With the increasing deployment of Ethernet in the access and > aggregation network, operators require consistent methods to test and > troubleshoot connectivity for mixed Ethernet and ATM access networks > (including the local loop). ANCP will allow a remote procedure for a > local loop connectivity test to be triggered from the NAS with results > communicated back to the NAS. > > [Stefaan] I would remove "via end-to-end ATM loopbacks" because the text > seems to suggest that ATM loopbacks have to be used consistently... > > MB> This sin't a requirement, but rather an explanation of how things are > today. How about "...via ATM OAM tools."? > Ok, by rereading it, it looks Ok. regards, Stefaan > > 4. Multicast > When multicast replication for subscriber-bound traffic is performed at > the AN, it offloads the network between the AN and NAS. However, a > subscriber's policy and configuration for multicast traffic may only be > known at the NAS. ANCP will provide a mechanism to communicate the > necessary information exchange between the AN and NAS so as to allow > the AN to perform subscriber bound multicast group replication in line > with the subscriber's policy and configuration, and also allow the NAS > to follow each subscriber's multicast group membership. > > Non-Goals: > > ANCP is an IP-based protocol that operates between the AN and NAS, over > a DSL access and aggregation network. It will not address setup or > configuration of circuits or connections in the access and aggregation > network itself. > > The focus of this WG is on one very specific application space. While > the design of the protocol should be general as to not preclude other > uses in the future should a need arise, it is not a goal of this WG > to address specific requirements outside of DSL access and aggregation > networks. > > > [Stefaan] A goal of the working group is to solve the requirements for > DSL access in such a way that the solution can be re-used later for > other technologies as well. Is is something that should be clearer in > the "goals" section. > > > > > regards, > Stefaan > > > > > _______________________________________________ L2cp mailing list L2cp@ietf.org https://www1.ietf.org/mailman/listinfo/l2cp From l2cp-bounces@ietf.org Wed May 24 07:46:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FirpA-00050G-4T; Wed, 24 May 2006 07:46:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Firp8-00050B-Fg for l2cp@ietf.org; Wed, 24 May 2006 07:46:46 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Firp6-0001jP-V7 for l2cp@ietf.org; Wed, 24 May 2006 07:46:46 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Wed, 24 May 2006 13:46:43 +0200 Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 24 May 2006 13:46:43 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED20EA053@S4DE8PSAAFQ.mitte.t-com.de> From: "Haag, T" To: Michel.Platnic@ecitele.com, swadhwa@juniper.net Subject: AW: [L2CP] RE: Wadhwa new draft 01- Encapsulation Date: Wed, 24 May 2006 13:46:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: cce76727b3e6fc1828f2a1e4df684182 Cc: l2cp@ietf.org X-BeenThere: l2cp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Layer 2 Control Protocol Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1139603142==" Errors-To: l2cp-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1139603142== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C67F27.B68A3B8F" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C67F27.B68A3B8F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Michel, Hi Sanjay, all, =20 First of all I agree to use already defined TLVs although it will not = solve our basic problem of mixing layer 1 and 2 information. =20 To use a TLV for encapsulation adds another mixing. Imagine you have = two different types (e.g. PPPoE + IPoE) of encapsulation at the same = time at the local loop.=20 =20 1. Does the model allow two different types at the same time?=20 2. Should the DSLAM send in upstream two different TLV's? 3. Supposed the DSLAM sends two TLV's what should the BNG do with it?=20 4. How can you adjust a shaper on that information? =20 I think these facts are not solved by TR-101 too. So I have some = concerns to follow TR-101 in that way and see some space for = improvement. =20 Regards Thomas=20 -----Urspr=FCngliche Nachricht----- Von: Michel.Platnic@ecitele.com [mailto:Michel.Platnic@ecitele.com]=20 Gesendet: Mittwoch, 24. Mai 2006 11:46 An: Sanjay Wadhwa Cc: l2cp@ietf.org Betreff: RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation=20 =20 Hi Sanjay and all,=20 I support Sanjay's proposal to have this encapsulation transported by = ANCP, even if we may argue that=20 we already have 2 protocols that may transport this information (DHCP = and PPPoE).=20 About having a different TLV to transport the Encapsulation, it only = partially solves the problem of potentially mixing=20 layer 1 and layer 2 information. Actually the DSL forum (TR-101) uses = same principle described in your document to transport this=20 information, it is probably wise to follow the same mechanism..=20 Unless other people share this concern, I'll go with your proposal.=20 Best Regards,=20 Michel.=20 "Sanjay Wadhwa" =20 24/05/2006 00:01=20 To =20 cc l2cp@ietf.org=20 Subject RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation + Remode Id comments =20 =20 =20 >-----Original Message----- >From: stefaan.de_cnodder@alcatel.be >[mailto:stefaan.de_cnodder@alcatel.be] >Sent: Tuesday, May 23, 2006 1:07 PM >To: Sanjay Wadhwa >Cc: l2cp@ietf.org >Subject: Re: [L2CP] RE: Wadhwa new draft 01- Encapsulation + Remode Id >comments > > > >Hi Sanjay, > >>=20 >> - Why was the access loop encapsulation object included within a >> message where all parameters transmitted are layer 1 oriented? >> There might be several encapsulations available per=20 >physical link, a >> new message could maybe better serve the purpose of >> transmitting the encapsulation parameters. >> [[SW]] I have sympathy for your arguement as I had a similar >> concern, which is why L2 encaps has been specified as a=20 >seprate and >> optional TLV (although same message). >> It is to an extent useful for the BNG to learn l2 encaps on the >> local-loop as it can in some cases allow for more=20 >accurate shaping >> of subscriber traffic. >>=20 > >Why not specifying the bandwidth at L2? Then the BNG just takes this=20 >bandwidth for shaping and it does not have to take care of what=20 >encapsulation has been used. Why bottering the BNG with the=20 >encap on the=20 >DSL line. And what if later someone wants to do the same on non-DSL=20 >access lines? Are we going to add encap types and updating the=20 >BNG with=20 >these new encap types to compute the correct shaping rate? I=20 >believe it=20 >would be better to specify the bandwidth at which the BNG has to = shape. [SW] Shaping on the BNG (based on counting bytes transmitted) needs to know the "byte adjustment" (under/over-head) due to difference in = encaps on the aggregation network and access loop. I suppose the access-node could indicate the absolute difference in terms of bytes between the = two encapsulations.. however, this might not be accurate as an aggregation switch upstream of the DSLAM could change the encaps (e.g. insert an outer VLAN tag). Ideally, the BNG needs to use the difference between it's encaps and the encaps on the local-loop. Also, the BNG needs to adjust for cell-tax if the local-loop is cell based. -Sanjay >regards, >Stefaan > > >> *Chapter 5.4.2* >> - Typo: >> Type (Access-Loop-Circuit-ID =3D 0x01) : defined in section = 5.4.1 >> Type (Access-Aggregation-Circuit-ID-Binary =3D 0x02): defined in >> section 5.4.1. =20 >> Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03) : defined in >> section 5.4.1. =20 >> These lines should be updated to comply to Chapter 5.4.1. >>=20 >> [[SW]] Will fix. >> =20 >> Thanks >> -Sanjay=20 >>=20 >> Thanks and Best Regards, >> Michel. >>=20 >>=20 >>=20 >>=20 >> *"Sanjay Wadhwa" * >>=20 >> 05/04/2006 19:22 >>=20 >> =20 >> To >> "Busschbach, Peter B \(Peter\)"=20 >, "Wojciech >> Dec \(wdec\)" , >> cc >> =20 >> Subject >> RE: [L2CP] Advantages of L2CP (was: Revised WG = Charter Draft) >>=20 >>=20 >> =20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Peter >> Please see inline.. >>=20 >> >-----Original Message----- >> >From: Busschbach, Peter B (Peter)=20 >[mailto:busschbach@lucent.com] >> >Sent: Wednesday, April 05, 2006 10:51 AM >> >To: 'Wojciech Dec (wdec)'; l2cp@ietf.org >> >Subject: [L2CP] Advantages of L2CP (was: Revised WG=20 >Charter Draft) >> > >> > >> >Hi Woj, >> > >> >To address the second half of our email exchange: >> > >> >I did notice the sentence that addressed Dave's concern. >> >However, my point was that the charter claims that L2CP will >> >have a specific benefit ("avoiding complex cross-organization >> >interactions"), while it is far from clear that in this >> >respect L2CP is any better than other solutions. >>=20 >> [Sanjay] All that the charter is saying is that L2C work=20 >will undertake >> use-cases that aim to simplify service management by=20 >avoiding complex >> cross-organization interactions. It is a nobel goal that=20 >L2C is striving >> to achieve.. What is wrong with that ? This is=20 >irrespective of wether >> other solutions can provide this or not. >> So, as an example, charter for a new dynamic routing=20 >protocol might say >> that it will strive to achieve fast network-wide=20 >convergence (which is a >> clear benefit over static routing). But, obviously it is=20 >ok for multiple >> dynamic routing protocols to work towards this goal and have = this >> explicitly stated in their charter. >>=20 >> -Sanjay >>=20 >>=20 >> >I believe that the charter should avoid stating benefits that >> >are debatable and therefore suggest that the text that I >> >quoted in my first email be deleted from the charter. >> > >> >Peter >> > >> >> -----Original Message----- >> >> From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] >> >> Sent: Wednesday, April 05, 2006 7:34 AM >> >> To: Busschbach, Peter B (Peter); l2cp@ietf.org >> >> Subject: RE: [L2CP] Re: Revised WG Charter Draft >> >> >> >> >> >> Hi Peter, >> >> >> >> To address 1) we have put in the following statement=20 >in the charter >> >> which you may have not noticed. >> >> >> >> "The protocol design will not preclude other uses of L2CP." >> >> >> >> WRT 2) we do not lay any claims to how different=20 >operators structure >> >> their data bases, and some are probably better at doing it >> >> than others. >> >> However it does seem to be a fairly common problem that the >> >> info related >> >> to a single subscriber's network service needs to be farmed >> >> out and fed >> >> into numerous custom built manager systems besides also the >> >Radius DB. >> >> The idea is to allow a mechanism, through the use of L2CP, >> >to have the >> >> Access node be provided with such information as and when >> >> needed by the >> >> NAS which in turn accesses a common repository like=20 >a Radius DB. >> >> Dave's statement was, I believe, in relation to different >> >> subject; that >> >> of a wholesale-retail operation, where indeed the >> >relationship is more >> >> complex. However we do plan on addressing this as=20 >evidenced by the >> >> statement in the charter: >> >> "L2CP will address security aspects of the control protocol, >> >including >> >> the trust model between NAS nodes and access nodes." >> >> >> >> Regards, >> >> Woj. >> >> >> >> -----Original Message----- >> >> From: Busschbach, Peter B (Peter)=20 >[mailto:busschbach@lucent.com] >> >> Sent: 04 April 2006 21:23 >> >> To: 'l2cp@ietf.org' >> >> Subject: [L2CP] Re: Revised WG Charter Draft >> >> >> >> I have two comments on the revised charter. >> >> >> >> 1) At the end of the BOF, Mark=20 >Townsley limited >> the scope of the >> >> working group. Unfortunately, this is not captured very >> >clearly in the >> >> meeting minutes. The critical sentence in the=20 >meeting minutes is >> "DSL >> >> but good engineers ...". I.e. the focus of the WG is=20 >to solve a >> >> particular issue in DSL access networks, but as good >> >> engineers we should >> >> not preclude the use of the protocol for other applications. >> >> >> >> I don't see the limited scope reflected in the new charter. >> >> >> >> 2) Under "Line Configuration". the=20 >charter says: >> >> >> >> > L2CP is intended to simplify the OSS=20 >infrastructure for service >> >> > management, allowing subscriber-related service data to be >> >> maintained >> >> > in fewer repositories (e.g. RADIUS server back-end=20 >database) >> while >> >> > avoiding complex cross-organization interactions. >> >> >> >> I don't understand how L2CP leads to fewer Radius server >> >back end data >> >> bases. I also don't understand how L2CP avoids=20 >cross-organizational >> >> interactions. There seems to be an assumption that it is ok >> >> for L2CP to >> >> cross organizational boundaries but not for other=20 >protocols. I don't >> >> think that is correct. At the BOF, Dave Allan pointed out =20 >> >> that this is >> >> one of the more difficult problems to solve. Therefore, I >> >believe that >> >> this text should be removed from the charter. >> >> >> >> Peter >> >> >> >> >> >> >> >> _______________________________________________ >> >> L2cp mailing list >> >> L2cp@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/l2cp >> >> >> > >> >_______________________________________________ >> >L2cp mailing list >> >L2cp@ietf.org >> >https://www1.ietf.org/mailman/listinfo/l2cp >> > >>=20 >> _______________________________________________ >> L2cp mailing list >> L2cp@ietf.org >> https://www1.ietf.org/mailman/listinfo/l2cp >>=20 >>=20 >>=20 >--------------------------------------------------------------- >--------- >>=20 >> _______________________________________________ >> L2cp mailing list >> L2cp@ietf.org >> https://www1.ietf.org/mailman/listinfo/l2cp > _______________________________________________ L2cp mailing list L2cp@ietf.org https://www1.ietf.org/mailman/listinfo/l2cp ------_=_NextPart_001_01C67F27.B68A3B8F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Michel, Hi Sanjay, all, First of all I agree to use already defined TLVs although = it will not solve our basic problem of mixing layer 1 and 2 = information. To use a TLV for encapsulation adds another mixing. Imagine = you have two different types (e.g. PPPoE + IPoE) of encapsulation at the = same time at the local loop. 1. Does the model allow two different types at the same = time? 2. Should the DSLAM send in upstream two different = TLV’s? 3. Supposed the DSLAM sends two TLV’s what should the = BNG do with it? 4. How can you adjust a shaper on that = information? I think these facts are not solved by TR-101 too. So I have = some concerns to follow TR-101 in that way and see some space for = improvement. Regards Thomas -----Urspr=FCngliche Nachricht----- Von: Michel.Platnic@ecitele.com= [mailto:Michel.Platnic@ecitele.com= ] Gesendet: Mittwoch, 24. Mai 2006 11:46 An: Sanjay Wadhwa Cc: l2cp@ietf.org Betreff: RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation = Hi Sanjay and = all, I support = Sanjay's proposal to have this encapsulation transported by ANCP, even if we may = argue that we already have = 2 protocols that may transport this information (DHCP and PPPoE). = About having a = different TLV to transport the Encapsulation, it only partially solves the = problem of potentially mixing layer 1 and = layer 2 information. Actually the DSL forum (TR-101) uses same principle = described in your document to transport this information, it = is probably wise to follow the same mechanism.. Unless other = people share this concern, I'll go with your proposal. Best = Regards, Michel. = "Sanjay Wadhwa" <swadhwa@juniper.net> 24/05/2006 = 00:01 To <stefaan.de_cnodder@= alcatel.be> cc l2cp@ietf.org Subject RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation + Remode Id = comments >-----Original Message----- >From: stefaan.de_cnodder@alcatel.be >[mailto:stefaan.de_cnodder@alcatel.be] >Sent: Tuesday, May 23, 2006 1:07 PM >To: Sanjay Wadhwa >Cc: l2cp@ietf.org >Subject: Re: [L2CP] RE: Wadhwa new draft 01- Encapsulation + = Remode Id >comments > > > >Hi Sanjay, > >> >> - Why was the access loop encapsulation = object included within a >> message where all parameters transmitted are = layer 1 oriented? >> There might be several encapsulations = available per >physical link, a >> new message could maybe better serve the = purpose of >> transmitting the encapsulation = parameters. >> [[SW]] I have sympathy for your arguement as = I had a similar >> concern, which is why L2 encaps has been = specified as a >seprate and >> optional TLV (although same = message). >> It is to an extent useful for the BNG to = learn l2 encaps on the >> local-loop as it can in some cases allow for = more >accurate shaping >> of subscriber traffic. >> > >Why not specifying the bandwidth at L2? Then the BNG just takes = this >bandwidth for shaping and it does not have to take care of what = >encapsulation has been used. Why bottering the BNG with the = >encap on the >DSL line. And what if later someone wants to do the same on = non-DSL >access lines? Are we going to add encap types and updating the = >BNG with >these new encap types to compute the correct shaping rate? I = >believe it >would be better to specify the bandwidth at which the BNG has = to shape. [SW] Shaping on the BNG (based on counting bytes transmitted) needs = to know the "byte adjustment" (under/over-head) due to = difference in encaps on the aggregation network and access loop. I suppose the = access-node could indicate the absolute difference in terms of bytes between = the two encapsulations.. however, this might not be accurate as an = aggregation switch upstream of the DSLAM could change the encaps (e.g. insert = an outer VLAN tag). Ideally, the BNG needs to use the difference = between it's encaps and the encaps on the local-loop. Also, the BNG needs = to adjust for cell-tax if the local-loop is cell based. -Sanjay >regards, >Stefaan > > >> *Chapter 5.4.2* >> - Typo: >> Type (Access-Loop-Circuit-ID =3D 0x01) : = defined in section 5.4.1 >> Type (Access-Aggregation-Circuit-ID-Binary = =3D 0x02): defined in >> section 5.4.1. = >> Type (Access-Aggregation-Circuit-ID-ASCII = =3D 0x03) : defined in >> section 5.4.1. >> These lines should be updated to comply to = Chapter 5.4.1. >> >> [[SW]] Will fix. >> >> Thanks >> -Sanjay >> >> Thanks and Best Regards, >> Michel. >> >> >> >> >> *"Sanjay Wadhwa" <swadhwa@juniper.net>* >> >> 05/04/2006 19:22 >> >> = >> To >> = "Busschbach, Peter B \(Peter\)" ><busschbach@lucent.com>, "Wojciech >> Dec \(wdec\)" <wdec@cisco.com>, <l2cp@ietf.org> >> cc >> = >> Subject >> = RE: [L2CP] Advantages of L2CP (was: Revised WG Charter = Draft) >> >> >> = >> >> >> >> >> >> Peter >> Please see inline.. >> >> >-----Original = Message----- >> >From: Busschbach, Peter B (Peter) = >[mailto:busschbach@lucent.com] >> >Sent: Wednesday, April 05, 2006 = 10:51 AM >> >To: 'Wojciech Dec (wdec)'; = l2cp@ietf.org >> >Subject: [L2CP] Advantages of L2CP = (was: Revised WG >Charter Draft) >> > >> > >> >Hi Woj, >> > >> >To address the second half of our = email exchange: >> > >> >I did notice the sentence that = addressed Dave's concern. >> >However, my point was that the = charter claims that L2CP will >> >have a specific benefit = ("avoiding complex cross-organization >> >interactions"), while it is = far from clear that in this >> >respect L2CP is any better than = other solutions. >> >> [Sanjay] All that the charter is saying is = that L2C work >will undertake >> use-cases that aim to simplify service = management by >avoiding complex >> cross-organization interactions. It is a = nobel goal that >L2C is striving >> to achieve.. What is wrong with that ? This = is >irrespective of wether >> other solutions can provide this or = not. >> So, as an example, charter for a new dynamic = routing >protocol might say >> that it will strive to achieve fast = network-wide >convergence (which is a >> clear benefit over static routing). But, = obviously it is >ok for multiple >> dynamic routing protocols to work towards = this goal and have this >> explicitly stated in their charter. >> >> -Sanjay >> >> >> >I believe that the charter should = avoid stating benefits that >> >are debatable and therefore = suggest that the text that I >> >quoted in my first email be = deleted from the charter. >> > >> >Peter >> > >> >> -----Original = Message----- >> >> From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] >> >> Sent: Wednesday, April 05, = 2006 7:34 AM >> >> To: Busschbach, Peter B = (Peter); l2cp@ietf.org >> >> Subject: RE: [L2CP] Re: = Revised WG Charter Draft >> >> >> >> >> >> Hi Peter, >> >> >> >> To address 1) we have put in = the following statement >in the charter >> >> which you may have not = noticed. >> >> >> >> "The protocol design = will not preclude other uses of L2CP." >> >> >> >> WRT 2) we do not lay any = claims to how different >operators structure >> >> their data bases, and some = are probably better at doing it >> >> than others. >> >> However it does seem to be a = fairly common problem that the >> >> info related >> >> to a single subscriber's = network service needs to be farmed >> >> out and fed >> >> into numerous custom built = manager systems besides also the >> >Radius DB. >> >> The idea is to allow a = mechanism, through the use of L2CP, >> >to have the >> >> Access node be provided with = such information as and when >> >> needed by the >> >> NAS which in turn accesses a = common repository like >a Radius DB. >> >> Dave's statement was, I = believe, in relation to different >> >> subject; that >> >> of a wholesale-retail = operation, where indeed the >> >relationship is more >> >> complex. However we do plan = on addressing this as >evidenced by the >> >> statement in the = charter: >> >> "L2CP will address = security aspects of the control protocol, >> >including >> >> the trust model between NAS = nodes and access nodes." >> >> >> >> Regards, >> >> Woj. >> >> >> >> -----Original = Message----- >> >> From: Busschbach, Peter B = (Peter) >[mailto:busschbach@lucent.com] >> >> Sent: 04 April 2006 = 21:23 >> >> To: 'l2cp@ietf.org' >> >> Subject: [L2CP] Re: Revised = WG Charter Draft >> >> >> >> I have two comments on the = revised charter. >> >> >> >> 1) = At the end of the BOF, Mark >Townsley limited >> the scope of the >> >> working group. Unfortunately, = this is not captured very >> >clearly in the >> >> meeting minutes. The critical sentence in the >meeting minutes is >> "DSL >> >> but good engineers ...". = I.e. the focus of the WG is >to solve a >> >> particular issue in DSL = access networks, but as good >> >> engineers we should >> >> not preclude the use of the = protocol for other applications. >> >> >> >> I don't see the limited scope reflected in the new charter. >> >> >> >> 2) = Under "Line Configuration". the = >charter says: >> >> >> >> > L2CP is intended to = simplify the OSS >infrastructure for service >> >> > management, allowing = subscriber-related service data to be >> >> maintained >> >> > in fewer repositories = (e.g. RADIUS server back-end >database) >> while >> >> > avoiding complex cross-organization interactions. >> >> >> >> I don't understand how L2CP = leads to fewer Radius server >> >back end data >> >> bases. I also don't = understand how L2CP avoids >cross-organizational >> >> interactions. There seems to = be an assumption that it is ok >> >> for L2CP to >> >> cross organizational = boundaries but not for other >protocols. I don't >> >> think that is correct. At the = BOF, Dave Allan pointed out >> >> that this is >> >> one of the more difficult = problems to solve. Therefore, I >> >believe that >> >> this text should be removed = from the charter. >> >> >> >> Peter >> >> >> >> >> >> >> >> _______________________________________________ >> >> L2cp mailing list >> >> L2cp@ietf.org >> >> = https://www1.ietf.org/mailman/listinfo/l2cp >> >> >> > >> >_______________________________________________ >> >L2cp mailing list >> >L2cp@ietf.org >> >https://www1.ietf.org/mailman/listinfo/l2cp >> > >> >> = _______________________________________________ >> L2cp mailing list >> L2cp@ietf.org >> = https://www1.ietf.org/mailman/listinfo/l2cp >> >> >> >---------------------------------------------------------------<= /tt> >--------- >> >> _______________________________________________ >> L2cp mailing list >> L2cp@ietf.org >> https://www1.ietf.org/mailman/listinfo/l2cp > _______________________________________________ L2cp mailing list L2cp@ietf.org https://www1.ietf.org/mailman/listinfo/l2cp ------_=_NextPart_001_01C67F27.B68A3B8F-- --===============1139603142== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ L2cp mailing list L2cp@ietf.org https://www1.ietf.org/mailman/listinfo/l2cp --===============1139603142==-- From l2cp-bounces@ietf.org Wed May 24 08:51:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fisq2-0003HQ-Cs; Wed, 24 May 2006 08:51:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fisq1-0003HL-BM for l2CP@ietf.org; Wed, 24 May 2006 08:51:45 -0400 Received: from smail.alcatel.fr ([64.208.49.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fispv-0005Ox-Qf for l2CP@ietf.org; Wed, 24 May 2006 08:51:45 -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 k4OCpVD7004468 for ; Wed, 24 May 2006 14:51:32 +0200 Received: from [138.203.192.189] ([138.203.192.189]) by bemail06.netfr.alcatel.fr (Lotus Domino Release 5.0.12HF868) with ESMTP id 2006052414512968:3635 ; Wed, 24 May 2006 14:51:29 +0200 Message-ID: <447456D2.4090905@alcatel.be> Date: Wed, 24 May 2006 14:51:30 +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: Matthew.Bocci@alcatel.co.uk Subject: Re: [L2CP] Updated LC charter References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 05/24/2006 14:51:29, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 05/24/2006 14:51:32, Serialize complete at 05/24/2006 14:51:32 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: e472ca43d56132790a46d9eefd95f0a5 Cc: l2CP@ietf.org X-BeenThere: l2cp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Layer 2 Control Protocol Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: l2cp-bounces@ietf.org Hi Matthew, In that case it is better to use the IETF terminology (NAS) and put a reference to the relevant RFC. One more comment on this part of the charter: "The focus of this WG is on one very specific application space. While the design of the protocol should be general as to not preclude other uses in the future should a need arise, it is not a goal of this WG to address specific requirements outside of DSL access and aggregation networks." This is rather vague to me. According to me the requirements are only comming from DSL, and the WG does not have to look to solutions for non-DSL requirements but the protocol that has to meet these requirements has to be DSL independent. For each requirement, there must be the necessary TLVs to meet the requirement. If a non-DSL access network has the same requirement, then the same TLVs can be used. For instance, advertising the bandwidth might be used for non-DSL as well, possibly by defining some extra encapsulation types in the existing sub-tlv if needed. This is to avoid that we have in the future many TLVs that are actually doing the same. Obviously, when there is a requirement to advertise certain DSL specific attributes, then this will result in a TLV that is only relevant for DSL but that is not a problem because non-DSL will never has this requirement and hence will not use the TLV. This will have impact on the protocols draft because it defines the TLV "DSL Line Attribute" which is too specific but I believe with renaming the TLVs/sub-TLVs and rewording the description, it can be made more general. regards, Stefaan Matthew.Bocci@alcatel.co.uk wrote: > Stefaan, > > On further investigation, it seems that RFC2881 describes a NAS in detail. > This appears to coincide with what the DSLF would term a BNG or BRAS. > > To keep with current IETF terminology, I suggest we continue to use NAS, > but add a reference to RFC2881 for the detailed NAS definition. > > Best regards, > > Matthew > > > > > Stefaan DE > CNODDER/BE/ALCATE > L@ALCATEL To > Matthew BOCCI/GB/ALCATEL@ALCATEL > 23/05/2006 11:10 cc > l2CP@ietf.org > Subject > Re: [L2CP] Updated LC charter > > > > > > > > > > > > Matthew, > > >>Network Access Server (NAS) - Network device which aggregates >>multiplexedSubscriber traffic from a number of Access Nodes. The NAS >>plays a central role in per-subsciber policy enforcement and QoS. Often >>referred to as an Broadband Network Gateway (BNG) or Broadband Remote >>Access Server (BRAS). >> >>[Stefaan] RFC2138 already define the term NAS. Is it the same >>definition? Is it needed to repeat it, if not the same then better to >>use another term. >> >>MB> Unfortunately they do not seem to be exactly the same, since the RFC >>assumes a RADIUS client in the NAS. Do you have any other suggestions? >>Could we just go with BNG, as per the DSL Forum? >> > > > BNG looks fine for me, and remove NAS to avoid confusion. > > > >>3. Remote Connectivity Test >>Traditional DSL access and aggregation networks employ point-to-point >>ATM circuits between the AN and NAS for each subscriber, allowing >>troubleshooting of the local loop from the NAS via end-to-end ATM >>loopbacks. With the increasing deployment of Ethernet in the access and >>aggregation network, operators require consistent methods to test and >>troubleshoot connectivity for mixed Ethernet and ATM access networks >>(including the local loop). ANCP will allow a remote procedure for a >>local loop connectivity test to be triggered from the NAS with results >>communicated back to the NAS. >> >>[Stefaan] I would remove "via end-to-end ATM loopbacks" because the text >>seems to suggest that ATM loopbacks have to be used consistently... >> >>MB> This sin't a requirement, but rather an explanation of how things are >>today. How about "...via ATM OAM tools."? >> > > > Ok, by rereading it, it looks Ok. > > regards, > Stefaan > > > >>4. Multicast >>When multicast replication for subscriber-bound traffic is performed at >>the AN, it offloads the network between the AN and NAS. However, a >>subscriber's policy and configuration for multicast traffic may only be >>known at the NAS. ANCP will provide a mechanism to communicate the >>necessary information exchange between the AN and NAS so as to allow >>the AN to perform subscriber bound multicast group replication in line >>with the subscriber's policy and configuration, and also allow the NAS >>to follow each subscriber's multicast group membership. >> >>Non-Goals: >> >>ANCP is an IP-based protocol that operates between the AN and NAS, over >>a DSL access and aggregation network. It will not address setup or >>configuration of circuits or connections in the access and aggregation >>network itself. >> >>The focus of this WG is on one very specific application space. While >>the design of the protocol should be general as to not preclude other >>uses in the future should a need arise, it is not a goal of this WG >>to address specific requirements outside of DSL access and aggregation >>networks. >> >> >>[Stefaan] A goal of the working group is to solve the requirements for >>DSL access in such a way that the solution can be re-used later for >>other technologies as well. Is is something that should be clearer in >>the "goals" section. >> >> >> >> >>regards, >>Stefaan >> >> >> >> >> > > > > > _______________________________________________ L2cp mailing list L2cp@ietf.org https://www1.ietf.org/mailman/listinfo/l2cp From l2cp-bounces@ietf.org Wed May 24 09:24:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FitM4-0006zD-9S; Wed, 24 May 2006 09:24:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FitM3-0006z8-CI for l2CP@ietf.org; Wed, 24 May 2006 09:24:51 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FitM1-0006mb-PX for l2CP@ietf.org; Wed, 24 May 2006 09:24:51 -0400 Received: from gbmail02.netfr.alcatel.fr (gbmail02.netfr.alcatel.fr [155.132.251.26]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k4ODOmBC000989 for ; Wed, 24 May 2006 15:24:48 +0200 In-Reply-To: <447456D2.4090905@alcatel.be> Subject: Re: [L2CP] Updated LC charter To: Stefaan De Cnodder X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Matthew.Bocci@alcatel.co.uk Date: Wed, 24 May 2006 14:24:43 +0100 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 05/24/2006 14:24:47 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Cc: l2CP@ietf.org X-BeenThere: l2cp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Layer 2 Control Protocol Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: l2cp-bounces@ietf.org Stefaan, The working group only has requirements for DSL at present, but I agree that the ANCP protocol should be engineered such that it can be applied to other access technologies in the future. The charter needs to be a bit clearer on this distinction, and so I suggest loosening the wording of the purpose and the AN definition, so that we do not preclude the AN from being something other than a DSLAM: "Purpose: The purpose of the ANCP WG is to standardize an IP based Access Node Control Protocol (ANCP) for use in service provider Digital Subscriber Line (DSL) access and aggregation networks. ANCP operates between an Access Node (AN) and Network Access Server (NAS). " "Access Node (AN) - Network device, usually located at a service provider central office, that terminates access loop connections from Subscribers. For DSL, this is often referred to as a Digital Subscriber Line Access Multiplexer (DSLAM)" best regards, Matthew Stefaan DE CNODDER/BE/ALCATE L@ALCATEL To Matthew BOCCI/GB/ALCATEL@ALCATEL 24/05/2006 13:51 cc l2CP@ietf.org Subject Re: [L2CP] Updated LC charter Hi Matthew, In that case it is better to use the IETF terminology (NAS) and put a reference to the relevant RFC. One more comment on this part of the charter: "The focus of this WG is on one very specific application space. While the design of the protocol should be general as to not preclude other uses in the future should a need arise, it is not a goal of this WG to address specific requirements outside of DSL access and aggregation networks." This is rather vague to me. According to me the requirements are only comming from DSL, and the WG does not have to look to solutions for non-DSL requirements but the protocol that has to meet these requirements has to be DSL independent. For each requirement, there must be the necessary TLVs to meet the requirement. If a non-DSL access network has the same requirement, then the same TLVs can be used. For instance, advertising the bandwidth might be used for non-DSL as well, possibly by defining some extra encapsulation types in the existing sub-tlv if needed. This is to avoid that we have in the future many TLVs that are actually doing the same. Obviously, when there is a requirement to advertise certain DSL specific attributes, then this will result in a TLV that is only relevant for DSL but that is not a problem because non-DSL will never has this requirement and hence will not use the TLV. This will have impact on the protocols draft because it defines the TLV "DSL Line Attribute" which is too specific but I believe with renaming the TLVs/sub-TLVs and rewording the description, it can be made more general. regards, Stefaan Matthew.Bocci@alcatel.co.uk wrote: > Stefaan, > > On further investigation, it seems that RFC2881 describes a NAS in detail. > This appears to coincide with what the DSLF would term a BNG or BRAS. > > To keep with current IETF terminology, I suggest we continue to use NAS, > but add a reference to RFC2881 for the detailed NAS definition. > > Best regards, > > Matthew > > > > > Stefaan DE > CNODDER/BE/ALCATE > L@ALCATEL To > Matthew BOCCI/GB/ALCATEL@ALCATEL > 23/05/2006 11:10 cc > l2CP@ietf.org > Subject > Re: [L2CP] Updated LC charter > > > > > > > > > > > > Matthew, > > >>Network Access Server (NAS) - Network device which aggregates >>multiplexedSubscriber traffic from a number of Access Nodes. The NAS >>plays a central role in per-subsciber policy enforcement and QoS. Often >>referred to as an Broadband Network Gateway (BNG) or Broadband Remote >>Access Server (BRAS). >> >>[Stefaan] RFC2138 already define the term NAS. Is it the same >>definition? Is it needed to repeat it, if not the same then better to >>use another term. >> >>MB> Unfortunately they do not seem to be exactly the same, since the RFC >>assumes a RADIUS client in the NAS. Do you have any other suggestions? >>Could we just go with BNG, as per the DSL Forum? >> > > > BNG looks fine for me, and remove NAS to avoid confusion. > > > >>3. Remote Connectivity Test >>Traditional DSL access and aggregation networks employ point-to-point >>ATM circuits between the AN and NAS for each subscriber, allowing >>troubleshooting of the local loop from the NAS via end-to-end ATM >>loopbacks. With the increasing deployment of Ethernet in the access and >>aggregation network, operators require consistent methods to test and >>troubleshoot connectivity for mixed Ethernet and ATM access networks >>(including the local loop). ANCP will allow a remote procedure for a >>local loop connectivity test to be triggered from the NAS with results >>communicated back to the NAS. >> >>[Stefaan] I would remove "via end-to-end ATM loopbacks" because the text >>seems to suggest that ATM loopbacks have to be used consistently... >> >>MB> This sin't a requirement, but rather an explanation of how things are >>today. How about "...via ATM OAM tools."? >> > > > Ok, by rereading it, it looks Ok. > > regards, > Stefaan > > > >>4. Multicast >>When multicast replication for subscriber-bound traffic is performed at >>the AN, it offloads the network between the AN and NAS. However, a >>subscriber's policy and configuration for multicast traffic may only be >>known at the NAS. ANCP will provide a mechanism to communicate the >>necessary information exchange between the AN and NAS so as to allow >>the AN to perform subscriber bound multicast group replication in line >>with the subscriber's policy and configuration, and also allow the NAS >>to follow each subscriber's multicast group membership. >> >>Non-Goals: >> >>ANCP is an IP-based protocol that operates between the AN and NAS, over >>a DSL access and aggregation network. It will not address setup or >>configuration of circuits or connections in the access and aggregation >>network itself. >> >>The focus of this WG is on one very specific application space. While >>the design of the protocol should be general as to not preclude other >>uses in the future should a need arise, it is not a goal of this WG >>to address specific requirements outside of DSL access and aggregation >>networks. >> >> >>[Stefaan] A goal of the working group is to solve the requirements for >>DSL access in such a way that the solution can be re-used later for >>other technologies as well. Is is something that should be clearer in >>the "goals" section. >> >> >> >> >>regards, >>Stefaan >> >> >> >> >> > > > > > _______________________________________________ L2cp mailing list L2cp@ietf.org https://www1.ietf.org/mailman/listinfo/l2cp From l2cp-bounces@ietf.org Thu May 25 04:25:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjB9k-0003ps-L6; Thu, 25 May 2006 04:25:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjB9i-0003pn-JW for l2cp@ietf.org; Thu, 25 May 2006 04:25:18 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjB9h-0001hV-1r for l2cp@ietf.org; Thu, 25 May 2006 04:25:18 -0400 Received: from gbmail02.netfr.alcatel.fr (gbmail02.netfr.alcatel.fr [155.132.251.26]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k4P8PEnf021268; Thu, 25 May 2006 10:25:15 +0200 In-Reply-To: <6439282641581441A36F7F6F83ED2ED20EA044@S4DE8PSAAFQ.mitte.t-com.de> Subject: Re: AW: AW: [L2CP] Updated LC charter To: "Haag, T" X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Matthew.Bocci@alcatel.co.uk Date: Thu, 25 May 2006 09:25:05 +0100 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 05/25/2006 09:25:14 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Cc: l2cp@ietf.org X-BeenThere: l2cp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Layer 2 Control Protocol Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: l2cp-bounces@ietf.org Thomas, I agree with your point about multicast. However, I don't think that th= e original charter statement precluding signalling of the underlying aggregation network disallows this. The issue is more to do with how we= distribute NAS functionality. ANCP needs to be flexible enough to accommodate the envisaged access/aggregation architectures, and should = not limit the choice of architecture. I would propose that we add a statement to the effect that, for scalability, some use cases require that aspects of NAS or AN functiona= lity may be distributed in nodes in the aggregation network. In these cases,= ANCP can run between these nodes. Best regards, Matthew = =20 "Haag, T" = =20 = To=20 Matthew BOCCI/GB/ALCATEL@ALCATEL= =20 23/05/2006 11:56 = cc=20 l2cp@ietf.org = =20 Subj= ect=20 AW: AW: [L2CP] Updated LC charte= r =20 = =20 = =20 = =20 = =20 = =20 = =20 Matthew, Thanks for the response. Please see inline. Regards Thomas Thomas, Thanks for your comments. Please see below. Matthew "Haag, T" = To Matthew BOCCI/GB/ALCATEL@ALCATEL= 23/05/2006 11:18 = cc l2cp@ietf.org Subj= ect AW: [L2CP] Updated LC charter Matthew, Please see inline my comments: ? Necessary Terminology: Access Node (AN) - Network device, usually located at a service provider central office [Th. Haag] or street cabinet, that terminates D= SL connections from Subscribers. Often referred to as a Digital Subscriber Line Access Multiplexer (DSLAM) ? The ANCP WG will address the following four use-cases: 1. Dynamic Access Loop [Th.Haag] attributes Various queuing and scheduling mechanisms are used in access networks to avoid congestion while dealing with multiple flows and distinct QoS profiles. Communicating the access-loop [Th.Haag] status and attributes= and current DSL synchronization rate between the AN and Subscriber up to the NAS is desirable, particularly when the NAS is providing QoS for individual flows and subscribers. ANCP will provide a mechanism to communicate dynamic access-loop [Th.Haag] attributes from the AN to the NAS. ? Non-Goals: ANCP is an IP-based protocol that operates between the AN and NAS, over= a DSL access and aggregation network. It will not address [Th.Haag] net= work management operation of circuits or connections in the access and aggregation network itself [Th.Haag] but will not exclude use case rele= vant aspects of access and aggregation. MB> We should not loose the fact that ANCP is not a signalling protocol= for the establishment of ATM or Ethernet connectivity in the aggregation network. The current use cases do not require this, so I'm not sure tha= t I understand your point. TH> That's o.k but use case relevant aspects such as e.g. Multicast sho= uld not exclude that elements along the data path between BNG and DSLAM may= retrieve information and support use case specific functionality. I think of in case of multicast it may be the case that an aggregation device (aggregating street cabinet DSLAMs; scalability issue) can have = the multicast point which may be controlled by ANCP (e.g. configuration of access lists...;combined with IGMP snooping in the aggregation). The focus of this WG is on one very specific application space. While the design of the protocol should be general as to not preclude other uses in the future should a need arise, it is not a goal of this WG to address specific requirements outside of DSL access and aggregation networks. ? Keeping in mind the following comments of the minutes I propose the cha= nges regarding Non-goals. Mark Townsley: - we should not even precule other use of the protocol in other areas?. Mark Townsley: Scoping of that group is driving to solve existing= problem. We should use good engineering to build things to allow future problems but we should not try to solve everything from th= e start. Regards Thomas -----Urspr=FCngliche Nachricht----- Von: Matthew.Bocci@alcatel.co.uk [mailto:Matthew.Bocci@alcatel.co.uk] Gesendet: Montag, 22. Mai 2006 18:20 An: l2cp@ietf.org Betreff: [L2CP] Updated LC charter Folks, We received a number of comments back from our ADs on the draft charter= , following the last call that we issued a few weeks ago. Please find attached a new revision of the charter that incorporates th= ese comments. Please post any comments to the list by this Friday (26th May= ). This will be taken to the IESG once once the list has agreed to the revisions. best regards, Matthew (See attached file: ANCP-charter-220506.txt) = _______________________________________________ L2cp mailing list L2cp@ietf.org https://www1.ietf.org/mailman/listinfo/l2cp From l2cp-bounces@ietf.org Thu May 25 08:53:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjFLU-0000Gb-8p; Thu, 25 May 2006 08:53:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjFLT-0000GW-6q for l2cp@ietf.org; Thu, 25 May 2006 08:53:43 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjFLQ-0006yk-Sn for l2cp@ietf.org; Thu, 25 May 2006 08:53:43 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 25 May 2006 05:53:40 -0700 X-IronPort-AV: i="4.05,171,1146466800"; d="scan'208,217"; a="553461930:sNHT153304092" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation Date: Thu, 25 May 2006 08:53:39 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2803B756E9@proton.jnpr.net> In-Reply-To: <6439282641581441A36F7F6F83ED2ED20EA053@S4DE8PSAAFQ.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [L2CP] RE: Wadhwa new draft 01- Encapsulation Thread-Index: AcZ/J8wvTQ4hJKuEQ/+WX8Yi6kpD9AAGZexw From: "Sanjay Wadhwa" To: "Haag, T" , X-Spam-Score: 0.3 (/) X-Scan-Signature: e5f266f4274da5f9c358642fb34e0d4b Cc: l2cp@ietf.org X-BeenThere: l2cp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Layer 2 Control Protocol Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0811133533==" Errors-To: l2cp-bounces@ietf.org This is a multi-part message in MIME format. --===============0811133533== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C67FFA.3E8B0833" This is a multi-part message in MIME format. ------_=_NextPart_001_01C67FFA.3E8B0833 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Thomas The encapsulation is reported per ACI. If the two encaps correspond to = two different logical circuits (VLANs or VCs) on the same access line, = then we should be able to appropriately report it for both ACIs and = adjust the shaper on the BNG.=20 =20 -Sanjay =20 -----Original Message----- From: Haag, T [mailto:Thomas.Haag@t-systems.com] Sent: Wednesday, May 24, 2006 7:47 AM To: Michel.Platnic@ecitele.com; Sanjay Wadhwa Cc: l2cp@ietf.org Subject: AW: [L2CP] RE: Wadhwa new draft 01- Encapsulation=20 Hi Michel, Hi Sanjay, all, =20 First of all I agree to use already defined TLVs although it will not = solve our basic problem of mixing layer 1 and 2 information. =20 To use a TLV for encapsulation adds another mixing. Imagine you have two = different types (e.g. PPPoE + IPoE) of encapsulation at the same time at = the local loop.=20 =20 1. Does the model allow two different types at the same time?=20 2. Should the DSLAM send in upstream two different TLV's? 3. Supposed the DSLAM sends two TLV's what should the BNG do with it?=20 4. How can you adjust a shaper on that information? =20 I think these facts are not solved by TR-101 too. So I have some = concerns to follow TR-101 in that way and see some space for = improvement. =20 Regards Thomas=20 -----Urspr=FCngliche Nachricht----- Von: Michel.Platnic@ecitele.com [mailto:Michel.Platnic@ecitele.com]=20 Gesendet: Mittwoch, 24. Mai 2006 11:46 An: Sanjay Wadhwa Cc: l2cp@ietf.org Betreff: RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation=20 =20 Hi Sanjay and all,=20 I support Sanjay's proposal to have this encapsulation transported by = ANCP, even if we may argue that=20 we already have 2 protocols that may transport this information (DHCP = and PPPoE).=20 About having a different TLV to transport the Encapsulation, it only = partially solves the problem of potentially mixing=20 layer 1 and layer 2 information. Actually the DSL forum (TR-101) uses = same principle described in your document to transport this=20 information, it is probably wise to follow the same mechanism..=20 Unless other people share this concern, I'll go with your proposal.=20 Best Regards,=20 Michel.=20 "Sanjay Wadhwa" =20 24/05/2006 00:01=20 To =20 cc l2cp@ietf.org=20 Subject RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation + Remode Id comments =20 =20 =20 >-----Original Message----- >From: stefaan.de_cnodder@alcatel.be >[mailto:stefaan.de_cnodder@alcatel.be] >Sent: Tuesday, May 23, 2006 1:07 PM >To: Sanjay Wadhwa >Cc: l2cp@ietf.org >Subject: Re: [L2CP] RE: Wadhwa new draft 01- Encapsulation + Remode Id >comments > > > >Hi Sanjay, > >>=20 >> - Why was the access loop encapsulation object included within a >> message where all parameters transmitted are layer 1 oriented? >> There might be several encapsulations available per=20 >physical link, a >> new message could maybe better serve the purpose of >> transmitting the encapsulation parameters. >> [[SW]] I have sympathy for your arguement as I had a similar >> concern, which is why L2 encaps has been specified as a=20 >seprate and >> optional TLV (although same message). >> It is to an extent useful for the BNG to learn l2 encaps on the >> local-loop as it can in some cases allow for more=20 >accurate shaping >> of subscriber traffic. >>=20 > >Why not specifying the bandwidth at L2? Then the BNG just takes this=20 >bandwidth for shaping and it does not have to take care of what=20 >encapsulation has been used. Why bottering the BNG with the=20 >encap on the=20 >DSL line. And what if later someone wants to do the same on non-DSL=20 >access lines? Are we going to add encap types and updating the=20 >BNG with=20 >these new encap types to compute the correct shaping rate? I=20 >believe it=20 >would be better to specify the bandwidth at which the BNG has to shape. [SW] Shaping on the BNG (based on counting bytes transmitted) needs to know the "byte adjustment" (under/over-head) due to difference in encaps on the aggregation network and access loop. I suppose the access-node could indicate the absolute difference in terms of bytes between the two encapsulations.. however, this might not be accurate as an aggregation switch upstream of the DSLAM could change the encaps (e.g. insert an outer VLAN tag). Ideally, the BNG needs to use the difference between it's encaps and the encaps on the local-loop. Also, the BNG needs to adjust for cell-tax if the local-loop is cell based. -Sanjay >regards, >Stefaan > > >> *Chapter 5.4.2* >> - Typo: >> Type (Access-Loop-Circuit-ID =3D 0x01) : defined in section 5.4.1 >> Type (Access-Aggregation-Circuit-ID-Binary =3D 0x02): defined in >> section 5.4.1. =20 >> Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03) : defined in >> section 5.4.1. =20 >> These lines should be updated to comply to Chapter 5.4.1. >>=20 >> [[SW]] Will fix. >> =20 >> Thanks >> -Sanjay=20 >>=20 >> Thanks and Best Regards, >> Michel. >>=20 >>=20 >>=20 >>=20 >> *"Sanjay Wadhwa" * >>=20 >> 05/04/2006 19:22 >>=20 >> =20 >> To >> "Busschbach, Peter B \(Peter\)"=20 >, "Wojciech >> Dec \(wdec\)" , >> cc >> =20 >> Subject >> RE: [L2CP] Advantages of L2CP (was: Revised WG = Charter Draft) >>=20 >>=20 >> =20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Peter >> Please see inline.. >>=20 >> >-----Original Message----- >> >From: Busschbach, Peter B (Peter)=20 >[mailto:busschbach@lucent.com] >> >Sent: Wednesday, April 05, 2006 10:51 AM >> >To: 'Wojciech Dec (wdec)'; l2cp@ietf.org >> >Subject: [L2CP] Advantages of L2CP (was: Revised WG=20 >Charter Draft) >> > >> > >> >Hi Woj, >> > >> >To address the second half of our email exchange: >> > >> >I did notice the sentence that addressed Dave's concern. >> >However, my point was that the charter claims that L2CP will >> >have a specific benefit ("avoiding complex cross-organization >> >interactions"), while it is far from clear that in this >> >respect L2CP is any better than other solutions. >>=20 >> [Sanjay] All that the charter is saying is that L2C work=20 >will undertake >> use-cases that aim to simplify service management by=20 >avoiding complex >> cross-organization interactions. It is a nobel goal that=20 >L2C is striving >> to achieve.. What is wrong with that ? This is=20 >irrespective of wether >> other solutions can provide this or not. >> So, as an example, charter for a new dynamic routing=20 >protocol might say >> that it will strive to achieve fast network-wide=20 >convergence (which is a >> clear benefit over static routing). But, obviously it is=20 >ok for multiple >> dynamic routing protocols to work towards this goal and have this >> explicitly stated in their charter. >>=20 >> -Sanjay >>=20 >>=20 >> >I believe that the charter should avoid stating benefits that >> >are debatable and therefore suggest that the text that I >> >quoted in my first email be deleted from the charter. >> > >> >Peter >> > >> >> -----Original Message----- >> >> From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] >> >> Sent: Wednesday, April 05, 2006 7:34 AM >> >> To: Busschbach, Peter B (Peter); l2cp@ietf.org >> >> Subject: RE: [L2CP] Re: Revised WG Charter Draft >> >> >> >> >> >> Hi Peter, >> >> >> >> To address 1) we have put in the following statement=20 >in the charter >> >> which you may have not noticed. >> >> >> >> "The protocol design will not preclude other uses of L2CP." >> >> >> >> WRT 2) we do not lay any claims to how different=20 >operators structure >> >> their data bases, and some are probably better at doing it >> >> than others. >> >> However it does seem to be a fairly common problem that the >> >> info related >> >> to a single subscriber's network service needs to be farmed >> >> out and fed >> >> into numerous custom built manager systems besides also the >> >Radius DB. >> >> The idea is to allow a mechanism, through the use of L2CP, >> >to have the >> >> Access node be provided with such information as and when >> >> needed by the >> >> NAS which in turn accesses a common repository like=20 >a Radius DB. >> >> Dave's statement was, I believe, in relation to different >> >> subject; that >> >> of a wholesale-retail operation, where indeed the >> >relationship is more >> >> complex. However we do plan on addressing this as=20 >evidenced by the >> >> statement in the charter: >> >> "L2CP will address security aspects of the control protocol, >> >including >> >> the trust model between NAS nodes and access nodes." >> >> >> >> Regards, >> >> Woj. >> >> >> >> -----Original Message----- >> >> From: Busschbach, Peter B (Peter)=20 >[mailto:busschbach@lucent.com] >> >> Sent: 04 April 2006 21:23 >> >> To: 'l2cp@ietf.org' >> >> Subject: [L2CP] Re: Revised WG Charter Draft >> >> >> >> I have two comments on the revised charter. >> >> >> >> 1) At the end of the BOF, Mark=20 >Townsley limited >> the scope of the >> >> working group. Unfortunately, this is not captured very >> >clearly in the >> >> meeting minutes. The critical sentence in the=20 >meeting minutes is >> "DSL >> >> but good engineers ...". I.e. the focus of the WG is=20 >to solve a >> >> particular issue in DSL access networks, but as good >> >> engineers we should >> >> not preclude the use of the protocol for other applications. >> >> >> >> I don't see the limited scope reflected in the new charter. >> >> >> >> 2) Under "Line Configuration". the=20 >charter says: >> >> >> >> > L2CP is intended to simplify the OSS=20 >infrastructure for service >> >> > management, allowing subscriber-related service data to be >> >> maintained >> >> > in fewer repositories (e.g. RADIUS server back-end=20 >database) >> while >> >> > avoiding complex cross-organization interactions. >> >> >> >> I don't understand how L2CP leads to fewer Radius server >> >back end data >> >> bases. I also don't understand how L2CP avoids=20 >cross-organizational >> >> interactions. There seems to be an assumption that it is ok >> >> for L2CP to >> >> cross organizational boundaries but not for other=20 >protocols. I don't >> >> think that is correct. At the BOF, Dave Allan pointed out =20 >> >> that this is >> >> one of the more difficult problems to solve. Therefore, I >> >believe that >> >> this text should be removed from the charter. >> >> >> >> Peter >> >> >> >> >> >> >> >> _______________________________________________ >> >> L2cp mailing list >> >> L2cp@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/l2cp >> >> >> > >> >_______________________________________________ >> >L2cp mailing list >> >L2cp@ietf.org >> >https://www1.ietf.org/mailman/listinfo/l2cp >> > >>=20 >> _______________________________________________ >> L2cp mailing list >> L2cp@ietf.org >> https://www1.ietf.org/mailman/listinfo/l2cp >>=20 >>=20 >>=20 >--------------------------------------------------------------- >--------- >>=20 >> _______________________________________________ >> L2cp mailing list >> L2cp@ietf.org >> https://www1.ietf.org/mailman/listinfo/l2cp > _______________________________________________ L2cp mailing list L2cp@ietf.org https://www1.ietf.org/mailman/listinfo/l2cp ------_=_NextPart_001_01C67FFA.3E8B0833 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi=20 Thomas =20 The encapsulation is reported per ACI. If the two encaps correspond to = two=20 different logical circuits (VLANs or VCs) on the same access line, then = we=20 should be able to appropriately report it for both ACIs and adjust the = shaper on=20 the BNG. -Sanjay -----Original=20 Message----- From: Haag, T=20 [mailto:Thomas.Haag@t-systems.com] Sent: Wednesday, May 24, = 2006 7:47=20 AM To: Michel.Platnic@ecitele.com; Sanjay Wadhwa Cc: = l2cp@ietf.org Subject: AW: [L2CP] RE: Wadhwa new draft 01-=20 Encapsulation

Hi Michel, = Hi Sanjay,=20 all, First of = all I agree=20 to use already defined TLVs although it will not solve our basic = problem of=20 mixing layer 1 and 2 information. To use a = TLV for=20 encapsulation adds another mixing. Imagine you have two different = types (e.g.=20 PPPoE + IPoE) of encapsulation at the same time at the local loop. = 1. Does the = model=20 allow two different types at the same time? 2. Should = the DSLAM=20 send in upstream two different TLV’s? 3. Supposed = the DSLAM=20 sends two TLV’s what should the BNG do with it? 4. How can = you adjust=20 a shaper on that information? I think = these facts=20 are not solved by TR-101 too. So I have some concerns to follow TR-101 = in that=20 way and see some space for improvement. Regards Thomas -----Urspr=FCngliche=20 Nachricht----- Von: Michel.Platnic@ecitele.com [mailto:Michel.Platnic@ecitele.com] Gesendet: = Mittwoch,=20 24. Mai 2006 11:46 An: Sanjay Wadhwa Cc: = l2cp@ietf.org Betreff: RE: = [L2CP]=20 RE: Wadhwa new draft 01- Encapsulation Hi Sanjay and = all,=20 I support = Sanjay's=20 proposal to have this encapsulation transported by ANCP, even if we = may argue=20 that we=20 already have 2 protocols that may transport this information (DHCP and = PPPoE). About having a = different TLV=20 to transport the Encapsulation, it only partially solves the problem = of=20 potentially mixing layer 1 and layer 2 = information. Actually the DSL forum (TR-101) uses same principle = described in=20 your document to transport this information, it is = probably=20 wise to follow the same mechanism.. Unless other people = share=20 this concern, I'll go with your proposal. Best = Regards,=20 Michel.=20 "Sanjay = Wadhwa"=20 <swadhwa@juniper.net> 24/05/2006=20 00:01 To <stefaan.de_cnodder@alcatel.be>=20 cc l2cp@ietf.org=20 Subject RE: = [L2CP] RE:=20 Wadhwa new draft 01- Encapsulation + Remode Id=20 comments
>-----Original=20 Message----- >From:=20 = stefaan.de_cnodder@alcatel.be >[mailto:stefaan.de_cnodder@= alcatel.be] >Sent:=20 Tuesday, May 23, 2006 1:07 PM >To: Sanjay=20 Wadhwa >Cc: l2cp@ietf.org >Subject: Re: = [L2CP]=20 RE: Wadhwa new draft 01- Encapsulation + Remode=20 = Id >comments > > > >Hi=20 Sanjay, > >> >> = =20 - Why was the access loop encapsulation object included within=20 a >> message where all parameters = transmitted=20 are layer 1 oriented? >> There might = be=20 several encapsulations available per >physical link,=20 a >> new message could maybe better = serve the=20 purpose of >> transmitting the = encapsulation=20 parameters. >> [[SW]] I have sympathy = for your=20 arguement as I had a similar >> = concern, which=20 is why L2 encaps has been specified as a >seprate=20 and >> optional TLV (although same=20 message). >> It is to an extent useful = for the=20 BNG to learn l2 encaps on the >> = local-loop as=20 it can in some cases allow for more >accurate=20 shaping >> of subscriber=20 traffic. >> > >Why = not=20 specifying the bandwidth at L2? Then the BNG just takes this=20 >bandwidth for shaping and it does not have to take = care of=20 what >encapsulation has been used. Why bottering the = BNG with=20 the >encap on the >DSL line. And what = if later=20 someone wants to do the same on non-DSL >access lines? = Are we=20 going to add encap types and updating the >BNG with=20 >these new encap types to compute the correct shaping = rate? I=20 >believe it >would be better to = specify the=20 bandwidth at which the BNG has to shape. [SW] Shaping = on the=20 BNG (based on counting bytes transmitted) needs to know = the "byte=20 adjustment" (under/over-head) due to difference in = encaps on the=20 aggregation network and access loop. I suppose the=20 access-node could indicate the absolute difference in = terms of=20 bytes between the two encapsulations.. however, this might = not be=20 accurate as an aggregation switch upstream of the DSLAM = could=20 change the encaps (e.g. insert an outer VLAN tag). = Ideally, the=20 BNG needs to use the difference between it's encaps and = the encaps=20 on the local-loop. Also, the BNG needs to adjust for = cell-tax if=20 the local-loop is cell=20 = based. -Sanjay >regards, <= TT>>Stefaan
>
>
>>=20 *Chapter 5.4.2*
>> -=20 Typo:
>> Type (Access-Loop-Circuit-ID = =3D 0x01)=20 : defined in section 5.4.1
>> Type=20 (Access-Aggregation-Circuit-ID-Binary =3D 0x02): defined = in
>>=20 section 5.4.1. =
>>=20 Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03) : = defined=20 in
>> section 5.4.1.=20
>> These lines should be = updated to=20 comply to Chapter 5.4.1.
>>
>> = =20 [[SW]] Will fix.
>> =20
>> Thanks
>> = =20 -Sanjay
>>
>> = =20 Thanks and Best Regards,
>> =20 Michel.
>>
>> =
>>=20
>>
>> *"Sanjay = Wadhwa"=20 <swadhwa@juniper.net>*
>> =
>> =20 05/04/2006 19:22
>>
>> = =20 =20
>> To
>> = =20 =20 "Busschbach, Peter B \(Peter\)"=20
><busschbach@lucent.com>, = "Wojciech
>>=20 Dec \(wdec\)" <wdec@cisco.com>,=20 <l2cp@ietf.org>
>> =20 cc
>> = =20
>> =20 Subject
>> = =20 RE: [L2CP] Advantages of L2CP (was: Revised = WG=20 Charter Draft)
>>
>>=20
>> = =20
>>
>>=20
>>
>>
>>=20
>> Peter
>> = =20 Please see inline..
>>
>> = =20 >-----Original Message-----
>> = =20 >From: Busschbach, Peter B (Peter)=20
>[mailto:busschbach@lucent.com]
>> = =20 >Sent: Wednesday, April 05, 2006 10:51 = AM
>>=20 >To: 'Wojciech Dec (wdec)';=20 l2cp@ietf.org
>> >Subject: = [L2CP]=20 Advantages of L2CP (was: Revised WG
>Charter=20 Draft)
>> = >
>>=20 >
>> = >Hi=20 Woj,
>> = >
>> =20 >To address the second half of our email=20 exchange:
>> = >
>>=20 >I did notice the sentence that addressed = Dave's=20 concern.
>> >However, my = point was=20 that the charter claims that L2CP will
>> = =20 >have a specific benefit ("avoiding complex=20 cross-organization
>> =20 >interactions"), while it is far from clear that in=20 this
>> >respect L2CP is any = better=20 than other solutions.
>>
>> = =20 [Sanjay] All that the charter is saying is that L2C work =
>will=20 undertake
>> use-cases that aim to = simplify=20 service management by
>avoiding = complex
>>=20 cross-organization interactions. It is a nobel goal that =
>L2C is striving
>> to = achieve.. What is wrong with that ? This is =
>irrespective of=20 wether
>> other solutions can provide = this or=20 not.
>> So, as an example, charter for = a new=20 dynamic routing
>protocol might = say
>>=20 that it will strive to achieve fast network-wide=20
>convergence (which is a
>> = =20 clear benefit over static routing). But, obviously it is =
>ok=20 for multiple
>> dynamic routing = protocols to=20 work towards this goal and have this
>> = =20 explicitly stated in their charter.
>> =
>>=20 -Sanjay
>>
>>=20
>> >I believe that the = charter=20 should avoid stating benefits that
>> =20 >are debatable and therefore suggest that the text that=20 I
>> >quoted in my first = email be=20 deleted from the charter.
>> =20 >
>> =20 >Peter
>> =20 >
>> >> = -----Original=20 Message-----
>> >> From: = Wojciech=20 Dec (wdec) [mailto:wdec@cisco.com]
>> =20 >> Sent: Wednesday, April 05, 2006 7:34 = AM
>>=20 >> To: Busschbach, Peter B (Peter);=20 l2cp@ietf.org
>> >> = Subject: RE:=20 [L2CP] Re: Revised WG Charter Draft
>> = >>
>> =20 >>
>> >> Hi=20 Peter,
>> = >>
>>=20 >> To address 1) we have put in the = following=20 statement
>in the charter
>> = =20 >> which you may have not noticed.
>> = =20 >>
>> = >> "The=20 protocol design will not preclude other uses of = L2CP."
>>=20 >>
>> = >>=20 WRT 2) we do not lay any claims to how different =
>operators=20 structure
>> >> their data = bases,=20 and some are probably better at doing it
>> = =20 >> than others.
>> = >>=20 However it does seem to be a fairly common problem that=20 the
>> >> info=20 related
>> >> to a single=20 subscriber's network service needs to be farmed
>> = =20 >> out and fed
>> =20 >> into numerous custom built manager systems besides also = the
>> >Radius=20 DB.
>> >> The idea is to = allow a=20 mechanism, through the use of L2CP,
>> = >to have the
>> = >> Access=20 node be provided with such information as and = when
>> =20 >> needed by the
>> = >> NAS which in turn accesses a common repository like=20
>a Radius DB.
>> =20 >> Dave's statement was, I believe, in relation to=20 different
>> >> subject;=20 that
>> >> of a = wholesale-retail=20 operation, where indeed the
>> =20 >relationship is more
>> =20 >> complex. However we do plan on addressing this as=20
>evidenced by the
>> =20 >> statement in the charter:
>> = =20 >> "L2CP will address security aspects of the control=20 protocol,
>> =20 >including
>> >> = the=20 trust model between NAS nodes and access nodes."
>> = =20 >>
>> = >>=20 Regards,
>> >>=20 Woj.
>> = >>
>>=20 >> -----Original = Message-----
>>=20 >> From: Busschbach, Peter B (Peter)=20
>[mailto:busschbach@lucent.com]
>> = =20 >> Sent: 04 April 2006 21:23
>> = =20 >> To: 'l2cp@ietf.org'
>> = =20 >> Subject: [L2CP] Re: Revised WG Charter=20 Draft
>> = >>
>>=20 >> I have two comments on the revised=20 charter.
>> =20 >>
>> >> 1) = =20 At the end of the = BOF, Mark=20
>Townsley limited
>> = the scope=20 of the
>> >> working = group.=20 Unfortunately, this is not captured very
>> = =20 >clearly in the
>> = >>=20 meeting minutes. The critical sentence in the
>meeting = minutes=20 is
>> "DSL
>> = =20 >> but good engineers ...". I.e. the focus of the WG is=20
>to solve a
>> = >>=20 particular issue in DSL access networks, but as = good
>>=20 >> engineers we should
>> = =20 >> not preclude the use of the protocol for other=20 applications.
>> =20 >>
>> >> I = don't see=20 the limited scope reflected in the new charter.
>> = =20 >>
>> = >> 2)=20 Under "Line=20 Configuration". the
>charter = says:
>> =20 >>
>> = >> >=20 L2CP is intended to simplify the OSS
>infrastructure = for=20 service
>> >> > = management,=20 allowing subscriber-related service data to be
>> = =20 >> maintained
>> =20 >> > in fewer repositories (e.g. RADIUS server back-end =
>database)
>> =20 while
>> >> > avoiding = complex=20 cross-organization interactions.
>> =20 >>
>> >> I = don't=20 understand how L2CP leads to fewer Radius server
>> = =20 >back end data
>> =20 >> bases. I also don't understand how L2CP avoids=20
>cross-organizational
>> = =20 >> interactions. There seems to be an assumption that it = is=20 ok
>> >> for L2CP=20 to
>> >> cross = organizational=20 boundaries but not for other
>protocols. I=20 don't
>> >> think that is = correct.=20 At the BOF, Dave Allan pointed out
>> = =20 >> that this is
>> = >>=20 one of the more difficult problems to solve. Therefore, = I
>>=20 >believe that
>> = =20 >> this text should be removed from the=20 charter.
>> =20 >>
>> >>=20 Peter
>> = >>
>>=20 >>
>> =20 >>
>> >>=20 _______________________________________________
>> = =20 >> L2cp mailing list
>> = =20 >> L2cp@ietf.org
>> = >>=20 https://www1.ietf.org/mailman/listinfo/l2cp
>> = =20 >>
>> =20 >
>> =20 = >_______________________________________________
>= ;>=20 >L2cp mailing list
>> = =20 >L2cp@ietf.org
>> =20 = >https://www1.ietf.org/mailman/listinfo/l2cp
>>= ;=20 >
>>
>> = =20 = _______________________________________________
>>=20 L2cp mailing list
>> =20 L2cp@ietf.org
>> =20 https://www1.ietf.org/mailman/listinfo/l2cp
>>=20
>>
>>=20 =
>--------------------------------------------------------= -------
>---------
>>=20
>>=20 _______________________________________________
>> = L2cp=20 mailing list
>> L2cp@ietf.org
>>=20 = https://www1.ietf.org/mailman/listinfo/l2cp
>

= _______________________________________________
L2cp=20 mailing=20 = list
L2cp@ietf.org
https://www1.ietf.org/mailman/= listinfo/l2cp

------_=_NextPart_001_01C67FFA.3E8B0833-- --===============0811133533== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ L2cp mailing list L2cp@ietf.org https://www1.ietf.org/mailman/listinfo/l2cp --===============0811133533==-- From l2cp-bounces@ietf.org Fri May 26 07:06:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fja9b-0001NP-LE; Fri, 26 May 2006 07:06:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fja9a-0001NK-Uy for l2cp@ietf.org; Fri, 26 May 2006 07:06:50 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fja9X-00033F-CQ for l2cp@ietf.org; Fri, 26 May 2006 07:06:50 -0400 Received: from gbmail02.netfr.alcatel.fr (gbmail02.netfr.alcatel.fr [155.132.251.26]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k4QB6Du5028750; Fri, 26 May 2006 13:06:46 +0200 Subject: Re: AW: AW: [L2CP] Updated LC charter To: "Haag, T" X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Matthew.Bocci@alcatel.co.uk Date: Fri, 26 May 2006 12:06:39 +0100 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 05/26/2006 12:06:45 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=0FBBFBE9DFAF11D28f9e8a93df938690918c0FBBFBE9DFAF11D2" Content-Disposition: inline X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: l2cp@ietf.org X-BeenThere: l2cp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Layer 2 Control Protocol Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: l2cp-bounces@ietf.org --0__=0FBBFBE9DFAF11D28f9e8a93df938690918c0FBBFBE9DFAF11D2 Content-type: text/plain; charset=us-ascii Here's the latest spin of the charter, incorporating comments received to date. Matthew (See attached file: ANCP-charter-260506.txt) --0__=0FBBFBE9DFAF11D28f9e8a93df938690918c0FBBFBE9DFAF11D2 Content-type: application/octet-stream; name="ANCP-charter-260506.txt" Content-Disposition: attachment; filename="ANCP-charter-260506.txt" Content-transfer-encoding: base64 QWNjZXNzIE5vZGUgQ29udHJvbCBQcm90b2NvbCAoQU5DUCkNCg0KDQpDdXJyZW50IFN0YXR1czog Tm9uLWV4aXN0aW5nIFdvcmtpbmcgR3JvdXANCg0KQ2hhaXIocyk6DQpNYXR0aGV3IEJvY2NpICht YXR0aGV3LmJvY2NpQGFsY2F0ZWwuY28udWspIA0KV29qY2llY2ggRGVjICh3ZGVjQGNpc2NvLmNv bSkNCg0KSW50ZXJuZXQgQXJlYSBEaXJlY3RvcihzKToNCk1hcmsgVG93bnNsZXkgPHRvd25zbGV5 QGNpc2NvLmNvbT4NCkphcmkgQXJra28gPGphcmkuYXJra29AcGl1aGEubmV0Pg0KDQpUZWNobmlj YWwgQWR2aXNvcihzKToNCkRhbiBSb21hc2NhbnUgPGRyb21hc2NhQGF2YXlhLmNvbT4NCg0KU2Vj cmV0YXJ5KGllcyk6DQpUQkQgPHRiZD4NCg0KQXJlYSBTcGVjaWZpYyBNYWlsaW5nIExpc3Q6DQpp bnQtYXJlYUBpZXRmLm9yZw0KDQpNYWlsaW5nIExpc3RzOg0KR2VuZXJhbCBEaXNjdXNzaW9uOiBh bmNwQGlldGYub3JnDQpUbyBTdWJzY3JpYmU6IGFuY3AtcmVxdWVzdEBpZXRmLm9yZw0KSW4gQm9k eTogc3Vic2NyaWJlIHlvdXJfZW1haWxfYWRkcmVzcw0KQXJjaGl2ZTogaHR0cDovL3d3dy5pZXRm Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL2FuY3AvaW5kZXguaHRtbA0KDQpQdXJwb3NlOg0KDQpUaGUg cHVycG9zZSBvZiB0aGUgQU5DUCBXRyBpcyB0byBzdGFuZGFyZGl6ZSBhbiBJUCBiYXNlZCBBY2Nl c3MgTm9kZSANCkNvbnRyb2wgUHJvdG9jb2wgKEFOQ1ApIGZvciB1c2UgaW4gc2VydmljZSBwcm92 aWRlciBEaWdpdGFsIFN1YnNjcmliZXIgDQpMaW5lIChEU0wpIGFjY2VzcyBhbmQgYWdncmVnYXRp b24gbmV0d29ya3MuIEFOQ1Agb3BlcmF0ZXMgYmV0d2VlbiBhbiANCkFjY2VzcyBOb2RlIChBTikg YW5kIE5ldHdvcmsgQWNjZXNzIFNlcnZlciAoTkFTKS4gDQoNCk5lY2Vzc2FyeSBUZXJtaW5vbG9n eToNCg0KQWNjZXNzIE5vZGUgKEFOKSAtIE5ldHdvcmsgZGV2aWNlLCB1c3VhbGx5IGxvY2F0ZWQg YXQgYSBzZXJ2aWNlIA0KcHJvdmlkZXIgY2VudHJhbCBvZmZpY2Ugb3Igc3RyZWV0IGNhYmluZXQs IHRoYXQgdGVybWluYXRlcyBhY2VzcyBsb29wIA0KY29ubmVjdGlvbnMgZnJvbSBTdWJzY3JpYmVy cy4gSW4gRFNMLCB0aGlzIGlzIG9mdGVuIHJlZmVycmVkIHRvIGFzIGEgDQpEaWdpdGFsIFN1YnNj cmliZXIgTGluZSBBY2Nlc3MgTXVsdGlwbGV4ZXIgKERTTEFNKQ0KDQpOZXR3b3JrIEFjY2VzcyBT ZXJ2ZXIgKE5BUykgLSBOZXR3b3JrIGRldmljZSB3aGljaCBhZ2dyZWdhdGVzIA0KbXVsdGlwbGV4 ZWRTdWJzY3JpYmVyIHRyYWZmaWMgZnJvbSBhIG51bWJlciBvZiBBY2Nlc3MgTm9kZXMuIFRoZSBO QVMgDQpwbGF5cyBhIGNlbnRyYWwgcm9sZSBpbiBwZXItc3Vic2NpYmVyIHBvbGljeSBlbmZvcmNl bWVudCBhbmQgUW9TLiBPZnRlbiANCnJlZmVycmVkIHRvIGFzIGFuIEJyb2FkYmFuZCBOZXR3b3Jr IEdhdGV3YXkgKEJORykgb3IgQnJvYWRiYW5kIFJlbW90ZSANCkFjY2VzcyBTZXJ2ZXIgKEJSQVMp LiBBIGRldGFpbGVkIGRlZmluaXRpb24gb2YgdGhlIE5BUyBpcyBnaXZlbiBpbiANClJGQzI4ODEu DQoNCkdvYWxzOg0KDQpBTkNQIGlzIGludGVuZGVkIHRvIGFkZHJlc3MgdGhlIHJlcXVpcmVtZW50 IGZvciBhIGJpZGlyZWN0aW9uYWwsIElQLQ0KYmFzZWQsIGNvbnRyb2wgcHJvdG9jb2wgdGhhdCBv cGVyYXRlcyBhY3Jvc3MgbXVsdGlwbGUgdHlwZXMgKGkuZS4sIA0KRXRoZXJuZXQsIEFUTSkgb2Yg RFNMIGFjY2VzcyBhbmQgYWdncmVnYXRpb24gbmV0d29ya3MuIFRoZSBnb2FsIG9mIGFuIA0KQU5D UCBtZXNzYWdlIGV4Y2hhbmdlIGlzIHRvIGNvbnZleSBzdGF0dXMgYW5kIGNvbnRyb2wgaW5mb3Jt YXRpb24gDQpiZXR3ZWVuIG9uZSBvciBtb3JlIEFOcyBhbmQgb25lIG9yIG1vcmUgTkFTcyB3aXRo b3V0IGdvaW5nIHRocm91Z2ggDQppbnRlcm1lZGlhdGUgZWxlbWVudCBtYW5hZ2Vycy4gDQoNClRo ZSBBTkNQIFdHIHdpbGwgYWRkcmVzcyB0aGUgZm9sbG93aW5nIGZvdXIgdXNlLWNhc2VzOg0KDQox LiBEeW5hbWljIEFjY2VzcyBMb29wIEF0dHJpYnV0ZXMNClZhcmlvdXMgcXVldWluZyBhbmQgc2No ZWR1bGluZyBtZWNoYW5pc21zIGFyZSB1c2VkIGluIGFjY2VzcyBuZXR3b3JrcyANCnRvIGF2b2lk IGNvbmdlc3Rpb24gd2hpbGUgZGVhbGluZyB3aXRoIG11bHRpcGxlIGZsb3dzIGFuZCBkaXN0aW5j dCBRb1MgDQpwcm9maWxlcy4gQ29tbXVuaWNhdGluZyB0aGUgYWNjZXNzLWxvb3Agc3RhdHVzLCBh dHRyaWJ1dGVzIGFuZCBjdXJyZW50IA0KRFNMIHN5bmNocm9uaXphdGlvbiByYXRlIGJldHdlZW4g dGhlIEFOIGFuZCBTdWJzY3JpYmVyIHVwIHRvIHRoZSBOQVMgaXMgDQpkZXNpcmFibGUsIHBhcnRp Y3VsYXJseSB3aGVuIHRoZSBOQVMgaXMgcHJvdmlkaW5nIFFvUyBmb3IgaW5kaXZpZHVhbCANCmZs b3dzIGFuZCBzdWJzY3JpYmVycy4gQU5DUCB3aWxsIHByb3ZpZGUgYSBtZWNoYW5pc20gdG8gY29t bXVuaWNhdGUgDQpkeW5hbWljIGFjY2Vzcy1sb29wIGF0dHJpYnV0ZXMgZnJvbSB0aGUgQU4gdG8g dGhlIE5BUy4NCg0KMi4gQWNjZXNzIExvb3AgQ29uZmlndXJhdGlvbg0KSW4gYWRkaXRpb25hbCB0 byByZXBvcnRpbmcgQWNjZXNzIExvb3AgY2hhcmFjdGVyaXN0aWNzIGZyb20gdGhlIEFOIHRvIA0K dGhlIE5BUywgQU5DUCB3aWxsIGFsbG93IGEgTkFTIHRvIHNlbmQgbG9vcC1zcGVjaWZpYyBjb25m aWd1cmF0aW9uIA0KaW5mb3JtYXRpb24gdG8gYW4gQU4gYmFzZWQgb24gdGhlIHJlc3VsdHMgb2Yg c3Vic2NyaWJlciBhdXRoZW50aWNhdGlvbiANCmFuZCBhdXRob3JpemF0aW9uIChlLmcuLCBhZnRl ciBBQUEgcmVzcG9uc2VzIGhhdmUgYmVlbiByZWNlaXZlZCBhdCB0aGUgDQpOQVMpLiANCg0KMy4g UmVtb3RlIENvbm5lY3Rpdml0eSBUZXN0DQpUcmFkaXRpb25hbCBEU0wgYWNjZXNzIGFuZCBhZ2dy ZWdhdGlvbiBuZXR3b3JrcyBlbXBsb3kgcG9pbnQtdG8tcG9pbnQgDQpBVE0gY2lyY3VpdHMgYmV0 d2VlbiB0aGUgQU4gYW5kIE5BUyBmb3IgZWFjaCBzdWJzY3JpYmVyLCBhbGxvd2luZyANCnRyb3Vi bGVzaG9vdGluZyBvZiB0aGUgbG9jYWwgbG9vcCBmcm9tIHRoZSBOQVMgdmlhIEFUTSBPQU0gdG9v bHMuIFdpdGggDQp0aGUgaW5jcmVhc2luZyBkZXBsb3ltZW50IG9mIEV0aGVybmV0IGluIHRoZSBh Y2Nlc3MgYW5kIGFnZ3JlZ2F0aW9uIA0KbmV0d29yaywgb3BlcmF0b3JzIHJlcXVpcmUgY29uc2lz dGVudCBtZXRob2RzIHRvIHRlc3QgYW5kIHRyb3VibGVzaG9vdCANCmNvbm5lY3Rpdml0eSBmb3Ig bWl4ZWQgRXRoZXJuZXQgYW5kIEFUTSBhY2Nlc3MgbmV0d29ya3MgKGluY2x1ZGluZyB0aGUgDQps b2NhbCBsb29wKS4gQU5DUCB3aWxsIGFsbG93IGEgcmVtb3RlIHByb2NlZHVyZSBmb3IgYSBsb2Nh bCBsb29wIA0KY29ubmVjdGl2aXR5IHRlc3QgdG8gYmUgdHJpZ2dlcmVkIGZyb20gdGhlIE5BUyB3 aXRoIHJlc3VsdHMgDQpjb21tdW5pY2F0ZWQgYmFjayB0byB0aGUgTkFTLiANCg0KNC4gTXVsdGlj YXN0DQpXaGVuIG11bHRpY2FzdCByZXBsaWNhdGlvbiBmb3Igc3Vic2NyaWJlci1ib3VuZCB0cmFm ZmljIGlzIHBlcmZvcm1lZCBhdA0KdGhlIEFOLCBpdCBvZmZsb2FkcyB0aGUgbmV0d29yayBiZXR3 ZWVuIHRoZSBBTiBhbmQgTkFTLiBIb3dldmVyLCBhDQpzdWJzY3JpYmVyJ3MgcG9saWN5IGFuZCBj b25maWd1cmF0aW9uIGZvciBtdWx0aWNhc3QgdHJhZmZpYyBtYXkgb25seSBiZQ0Ka25vd24gYXQg dGhlIE5BUy4gQU5DUCB3aWxsIHByb3ZpZGUgYSBtZWNoYW5pc20gdG8gY29tbXVuaWNhdGUgdGhl DQpuZWNlc3NhcnkgaW5mb3JtYXRpb24gZXhjaGFuZ2UgYmV0d2VlbiB0aGUgQU4gYW5kIE5BUyBz byBhcyB0byBhbGxvdyANCnRoZSBBTiB0byBwZXJmb3JtIHN1YnNjcmliZXIgYm91bmQgbXVsdGlj YXN0IGdyb3VwIHJlcGxpY2F0aW9uIGluIGxpbmUgDQp3aXRoIHRoZSBzdWJzY3JpYmVyJ3MgcG9s aWN5IGFuZCBjb25maWd1cmF0aW9uLCBhbmQgYWxzbyBhbGxvdyB0aGUgTkFTIA0KdG8gZm9sbG93 IGVhY2ggc3Vic2NyaWJlcidzIG11bHRpY2FzdCBncm91cCBtZW1iZXJzaGlwLg0KDQpOb24tR29h bHM6DQoNCkFOQ1AgaXMgYW4gSVAtYmFzZWQgcHJvdG9jb2wgdGhhdCBvcGVyYXRlcyBiZXR3ZWVu IHRoZSBBTiBhbmQgTkFTLCBvdmVyIA0KYSBEU0wgYWNjZXNzIGFuZCBhZ2dyZWdhdGlvbiBuZXR3 b3JrLiBJdCB3aWxsIG5vdCBhZGRyZXNzIHNldHVwIG9yIA0KY29uZmlndXJhdGlvbiBvZiBjaXJj dWl0cyBvciBjb25uZWN0aW9ucyBpbiB0aGUgYWNjZXNzIGFuZCBhZ2dyZWdhdGlvbiANCm5ldHdv cmsgaXRzZWxmLg0KDQpUaGUgZm9jdXMgb2YgdGhpcyBXRyBpcyBvbiBvbmUgdmVyeSBzcGVjaWZp YyBhcHBsaWNhdGlvbiBzcGFjZS4gV2hpbGUgDQp0aGUgZGVzaWduIG9mIHRoZSBwcm90b2NvbCBt dXN0IGJlIGdlbmVyYWwgYXMgdG8gbm90IHByZWNsdWRlIG90aGVyIA0KdXNlcyBpbiB0aGUgZnV0 dXJlIHNob3VsZCBhIG5lZWQgYXJpc2UsIGl0IGlzIG5vdCBhIGdvYWwgb2YgdGhpcyBXRw0KdG8g YWRkcmVzcyBzcGVjaWZpYyByZXF1aXJlbWVudHMgb3V0c2lkZSBvZiBEU0wgYWNjZXNzIGFuZCBh Z2dyZWdhdGlvbiANCm5ldHdvcmtzLiANCg0KU2VjdXJpdHk6DQoNClRoZSBBTkNQIHdvcmtpbmcg Z3JvdXAgd2lsbCBwcm92aWRlIGEgdGhyZWF0IGFuYWx5c2lzIGFuZCBhZGRyZXNzIHRoZSANCmFz c29jaWF0ZWQgc2VjdXJpdHkgYXNwZWN0cyBvZiB0aGUgY29udHJvbCBwcm90b2NvbC4gDQoNClJl c2lsaWVuY3kgYW5kIFNjYWxhYmlsdHk6IA0KDQpBIGdyYWNlZnVsIHJlc3RhcnQgbWVjaGFuaXNt IHdpbGwgYmUgZGVmaW5lZCB0byBlbmFibGUgdGhlIHByb3RvY29sIHRvIA0KYmUgcmVzaWxpZW50 IHRvIG5ldHdvcmsgZmFpbHVyZXMgYmV0d2VlbiB0aGUgQU4gYW5kIE5BUy4NCg0KU2NhbGFiaWxp dHkgYXQgdGhlIE5BUyBpcyBvZiBwcmltYXJ5IGNvbmNlcm4sIGFzIGl0IG1heSBiZSBhZ2dyZWdh dGluZyANCnRyYWZmaWMgZnJvbSBhIGxhcmdlIG51bWJlciBvZiBBTnMsIHdoaWNoIGluIHR1cm4g bWF5IGJlIHNlcnZpbmcgYSANCmxhcmdlIG51bWJlciBvZiBTdWJzY3JpYmVycy4gQU5DUCB0cmFm ZmljIHNob3VsZCBub3QgYmVjb21lIGEgZGVuaWFsIG9mIA0Kc2VydmljZSBhdHRhY2sgb24gdGhl IE5BUyBjb250cm9sIHBsYW5lLiBGb3JtYXQgb2YgbWVzc2FnZXMsIHBhY2luZywgDQp0cmFuc3Bv cnQgb3ZlciBVRFAgb3IgVENQLCBldGMuIHdpbGwgYmUgY29uc2lkZXJlZCB3aXRoIHRoaXMgaW4g bWluZC4NCg0KRm9yIHJlYXNvbnMgb2YgYWdncmVnYXRpb24gbmV0d29yayBzY2FsYWJpbGl0eSwg c29tZSB1c2UgY2FzZXMgcmVxdWlyZSANCnRoYXQgYXNwZWN0cyBvZiBOQVMgb3IgQU4gZnVuY3Rp b25hbGl0eSBtYXkgYmUgZGlzdHJpYnV0ZWQgaW4gbm9kZXMgaW4gDQp0aGUgYWdncmVnYXRpb24g bmV0d29yay4gSW4gdGhlc2UgY2FzZXMsIEFOQ1AgY2FuIHJ1biBiZXR3ZWVuIHRoZXNlIA0Kbm9k ZXMuDQoNCkRlbGl2ZXJhYmxlczoNCg0KVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBkZWZpbmUgYSBi YXNpYyBmcmFtZXdvcmsgYW5kIHJlcXVpcmVtZW50cyANCmRvY3VtZW50IGludGVuZGVkIGZvciBJ bmZvcm1hdGlvbmFsIHB1YmxpY2F0aW9uLCBmb2N1c2luZyBvbiB0aGUgZm91ciANCnVzZS1jYXNl cyBvdXRsaW5lZCBpbiB0aGlzIGNoYXJ0ZXIuIFRoaXMgZG9jdW1lbnQgd2lsbCBpbmNsdWRlIGEg DQpzZWN1cml0eSB0aHJlYXQgYW5hbHlzaXMgYW5kIGFzc29jaWF0ZWQgcmVxdWlyZW1lbnRzLiBU aGUgV0cgd2lsbCB0aGVuIA0KaW52ZXN0aWdhdGUgYW5kIGRlZmluZSBhIHNvbHV0aW9uIGZvciBh biBJUCBiYXNlZCBjb250cm9sIHByb3RvY29sIA0KbWVldGluZyB0aGVzZSByZXF1aXJlbWVudHMu IA0KDQpUaGVyZSBhcmUgZWFybHkgaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlvbnMgb2YgYW4g QU5DUC1saWtlIHByb3RvY29sIA0Kd2hpY2ggYXJlIGJhc2VkIG9uIGFuIGV4dGVuZGVkIHN1YnNl dCBvZiB0aGUgR1NNUHYzIHByb3RvY29sLiBUaGlzIA0KcnVubmluZyBjb2RlIHdpbGwgYmUgdGhl IHRoZSBzdGFydGluZyBwb2ludCBmb3IgdGhlIHdvcmtpbmcgZ3JvdXAgDQpzb2x1dGlvbiwgYW5k IHdpbGwgYmUgYWJhbmRvbmVkIG9ubHkgaWYgdGhlIFdHIGRldGVybWluZXMgaXQgaXMgbm90IA0K YWRlcXVhdGUgdG8gbWVldCByZXF1aXJlbWVudHMgZ29pbmcgZm9yd2FyZC4NCg0KR29hbHMgYW5k IE1pbGVzdG9uZXM6DQoNCk5vdmVtYmVyIDIwMDYgQWNjZXB0IFdHIEktRCBmb3IgQU5DUCBGcmFt ZXdvcmsgYW5kIFJlcXVpcmVtZW50cyANCk5vdmVtYmVyIDIwMDYgQWNjZXB0IFdHIEktRCBmb3Ig QWNjZXNzIE5vZGUgQ29udHJvbCBQcm90b2NvbCAoQU5DUCkNCkphbnVhcnkgMjAwNyAgRnJhbWV3 b3JrIGFuZCBSZXF1aXJlbWVudHMgbGFzdCBjYWxsDQpNYXJjaCAyMDA3ICAgIEFjY2VwdCBXRyBJ LUQgZm9yIEFOQ1AgTUlCDQpBcHJpbCAyMDA3ICAgIEFjY2VzcyBOb2RlIENvbnRyb2wgUHJvdG9j b2wgKEFOQ1ApIExhc3QgQ2FsbA0KTWF5IDIwMDcgICAgICBBTkNQIE1JQiBMYXN0IENhbGwNCkp1 bHkgMjAwNyAgICAgUmUtY2hhcnRlciBvciBjb25jbHVkZSBXb3JraW5nIEdyb3VwDQoNCkludGVy bmV0LURyYWZ0czoNCg== --0__=0FBBFBE9DFAF11D28f9e8a93df938690918c0FBBFBE9DFAF11D2 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ L2cp mailing list L2cp@ietf.org https://www1.ietf.org/mailman/listinfo/l2cp --0__=0FBBFBE9DFAF11D28f9e8a93df938690918c0FBBFBE9DFAF11D2-- From l2cp-bounces@ietf.org Mon May 29 03:50:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkcVq-00059T-7E; Mon, 29 May 2006 03:50:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkcVo-00056b-BB for l2cp@ietf.org; Mon, 29 May 2006 03:50:04 -0400 Received: from ilsmtp01.ecitele.com ([147.234.1.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkcVl-0005B3-F4 for l2cp@ietf.org; Mon, 29 May 2006 03:50:04 -0400 In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2803B756E9@proton.jnpr.net> To: "Sanjay Wadhwa" Subject: RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.3 September 14, 2004 Message-ID: From: Michel.Platnic@ecitele.com Date: Mon, 29 May 2006 10:49:53 +0300 X-MIMETrack: Serialize by Router on ILSMTP01/ECI Telecom(Release 6.5.3FP1 | December 22, 2004) at 05/29/2006 10:58:00, Serialize complete at 05/29/2006 10:58:00 X-Spam-Score: 0.3 (/) X-Scan-Signature: 33fc46667f70a87403df4cb21ee8343c Cc: "Haag, T" , l2cp@ietf.org X-BeenThere: l2cp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Layer 2 Control Protocol Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1342180152==" Errors-To: l2cp-bounces@ietf.org This is a multipart message in MIME format. --===============1342180152== Content-Type: multipart/alternative; boundary="=_alternative 002B09ABC225717D_=" This is a multipart message in MIME format. --=_alternative 002B09ABC225717D_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi Thomas, Sanjay, How should we send information in the example Thomas gave? Clear: If we have on the same DSL port 2 encapsulations on 2 different VLANs or=20 VCs, then we should send 2 messages (each having a different ACI) - ACI in this case must include=20 layer 1+ layer 2 identifiers. Unclear: Should we send Layer 1 information in both messages, in one of them, in a=20 different message? Regards, Michel. "Sanjay Wadhwa" =20 25/05/2006 15:53 To "Haag, T" , cc Subject RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation Hi Thomas The encapsulation is reported per ACI. If the two encaps correspond to=20 two different logical circuits (VLANs or VCs) on the same access line,=20 then we should be able to appropriately report it for both ACIs and adjust = the shaper on the BNG.=20 =20 -Sanjay =20 -----Original Message----- From: Haag, T [mailto:Thomas.Haag@t-systems.com] Sent: Wednesday, May 24, 2006 7:47 AM To: Michel.Platnic@ecitele.com; Sanjay Wadhwa Cc: l2cp@ietf.org Subject: AW: [L2CP] RE: Wadhwa new draft 01- Encapsulation=20 Hi Michel, Hi Sanjay, all, =20 First of all I agree to use already defined TLVs although it will not=20 solve our basic problem of mixing layer 1 and 2 information. =20 To use a TLV for encapsulation adds another mixing. Imagine you have two=20 different types (e.g. PPPoE + IPoE) of encapsulation at the same time at=20 the local loop.=20 =20 1. Does the model allow two different types at the same time?=20 2. Should the DSLAM send in upstream two different TLV?s? 3. Supposed the DSLAM sends two TLV?s what should the BNG do with it?=20 4. How can you adjust a shaper on that information? =20 I think these facts are not solved by TR-101 too. So I have some concerns=20 to follow TR-101 in that way and see some space for improvement. =20 Regards Thomas=20 -----Urspr=FCngliche Nachricht----- Von: Michel.Platnic@ecitele.com [mailto:Michel.Platnic@ecitele.com]=20 Gesendet: Mittwoch, 24. Mai 2006 11:46 An: Sanjay Wadhwa Cc: l2cp@ietf.org Betreff: RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation=20 =20 Hi Sanjay and all,=20 I support Sanjay's proposal to have this encapsulation transported by=20 ANCP, even if we may argue that=20 we already have 2 protocols that may transport this information (DHCP and=20 PPPoE).=20 About having a different TLV to transport the Encapsulation, it only=20 partially solves the problem of potentially mixing=20 layer 1 and layer 2 information. Actually the DSL forum (TR-101) uses same = principle described in your document to transport this=20 information, it is probably wise to follow the same mechanism..=20 Unless other people share this concern, I'll go with your proposal.=20 Best Regards,=20 Michel.=20 "Sanjay Wadhwa" =20 24/05/2006 00:01=20 To =20 cc l2cp@ietf.org=20 Subject RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation + Remode Id comments =20 =20 =20 >-----Original Message----- >From: stefaan.de=5Fcnodder@alcatel.be >[mailto:stefaan.de=5Fcnodder@alcatel.be] >Sent: Tuesday, May 23, 2006 1:07 PM >To: Sanjay Wadhwa >Cc: l2cp@ietf.org >Subject: Re: [L2CP] RE: Wadhwa new draft 01- Encapsulation + Remode Id >comments > > > >Hi Sanjay, > >>=20 >> - Why was the access loop encapsulation object included within a >> message where all parameters transmitted are layer 1 oriented? >> There might be several encapsulations available per=20 >physical link, a >> new message could maybe better serve the purpose of >> transmitting the encapsulation parameters. >> [[SW]] I have sympathy for your arguement as I had a similar >> concern, which is why L2 encaps has been specified as a=20 >seprate and >> optional TLV (although same message). >> It is to an extent useful for the BNG to learn l2 encaps on the >> local-loop as it can in some cases allow for more=20 >accurate shaping >> of subscriber traffic. >>=20 > >Why not specifying the bandwidth at L2? Then the BNG just takes this=20 >bandwidth for shaping and it does not have to take care of what=20 >encapsulation has been used. Why bottering the BNG with the=20 >encap on the=20 >DSL line. And what if later someone wants to do the same on non-DSL=20 >access lines? Are we going to add encap types and updating the=20 >BNG with=20 >these new encap types to compute the correct shaping rate? I=20 >believe it=20 >would be better to specify the bandwidth at which the BNG has to shape. [SW] Shaping on the BNG (based on counting bytes transmitted) needs to know the "byte adjustment" (under/over-head) due to difference in encaps on the aggregation network and access loop. I suppose the access-node could indicate the absolute difference in terms of bytes between the two encapsulations.. however, this might not be accurate as an aggregation switch upstream of the DSLAM could change the encaps (e.g. insert an outer VLAN tag). Ideally, the BNG needs to use the difference between it's encaps and the encaps on the local-loop. Also, the BNG needs to adjust for cell-tax if the local-loop is cell based. -Sanjay >regards, >Stefaan > > >> *Chapter 5.4.2* >> - Typo: >> Type (Access-Loop-Circuit-ID =3D 0x01) : defined in section 5.4.1 >> Type (Access-Aggregation-Circuit-ID-Binary =3D 0x02): defined in >> section 5.4.1.=20 >> Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03) : defined in >> section 5.4.1.=20 >> These lines should be updated to comply to Chapter 5.4.1. >>=20 >> [[SW]] Will fix. >>=20 >> Thanks >> -Sanjay=20 >>=20 >> Thanks and Best Regards, >> Michel. >>=20 >>=20 >>=20 >>=20 >> *"Sanjay Wadhwa" * >>=20 >> 05/04/2006 19:22 >>=20 >>=20 >> To >> "Busschbach, Peter B \(Peter\)"=20 >, "Wojciech >> Dec \(wdec\)" , >> cc >>=20 >> Subject >> RE: [L2CP] Advantages of L2CP (was: Revised WG=20 Charter Draft) >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Peter >> Please see inline.. >>=20 >> >-----Original Message----- >> >From: Busschbach, Peter B (Peter)=20 >[mailto:busschbach@lucent.com] >> >Sent: Wednesday, April 05, 2006 10:51 AM >> >To: 'Wojciech Dec (wdec)'; l2cp@ietf.org >> >Subject: [L2CP] Advantages of L2CP (was: Revised WG=20 >Charter Draft) >> > >> > >> >Hi Woj, >> > >> >To address the second half of our email exchange: >> > >> >I did notice the sentence that addressed Dave's concern. >> >However, my point was that the charter claims that L2CP will >> >have a specific benefit ("avoiding complex cross-organization >> >interactions"), while it is far from clear that in this >> >respect L2CP is any better than other solutions. >>=20 >> [Sanjay] All that the charter is saying is that L2C work=20 >will undertake >> use-cases that aim to simplify service management by=20 >avoiding complex >> cross-organization interactions. It is a nobel goal that=20 >L2C is striving >> to achieve.. What is wrong with that ? This is=20 >irrespective of wether >> other solutions can provide this or not. >> So, as an example, charter for a new dynamic routing=20 >protocol might say >> that it will strive to achieve fast network-wide=20 >convergence (which is a >> clear benefit over static routing). But, obviously it is=20 >ok for multiple >> dynamic routing protocols to work towards this goal and have this >> explicitly stated in their charter. >>=20 >> -Sanjay >>=20 >>=20 >> >I believe that the charter should avoid stating benefits that >> >are debatable and therefore suggest that the text that I >> >quoted in my first email be deleted from the charter. >> > >> >Peter >> > >> >> -----Original Message----- >> >> From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] >> >> Sent: Wednesday, April 05, 2006 7:34 AM >> >> To: Busschbach, Peter B (Peter); l2cp@ietf.org >> >> Subject: RE: [L2CP] Re: Revised WG Charter Draft >> >> >> >> >> >> Hi Peter, >> >> >> >> To address 1) we have put in the following statement=20 >in the charter >> >> which you may have not noticed. >> >> >> >> "The protocol design will not preclude other uses of L2CP." >> >> >> >> WRT 2) we do not lay any claims to how different=20 >operators structure >> >> their data bases, and some are probably better at doing it >> >> than others. >> >> However it does seem to be a fairly common problem that the >> >> info related >> >> to a single subscriber's network service needs to be farmed >> >> out and fed >> >> into numerous custom built manager systems besides also the >> >Radius DB. >> >> The idea is to allow a mechanism, through the use of L2CP, >> >to have the >> >> Access node be provided with such information as and when >> >> needed by the >> >> NAS which in turn accesses a common repository like=20 >a Radius DB. >> >> Dave's statement was, I believe, in relation to different >> >> subject; that >> >> of a wholesale-retail operation, where indeed the >> >relationship is more >> >> complex. However we do plan on addressing this as=20 >evidenced by the >> >> statement in the charter: >> >> "L2CP will address security aspects of the control protocol, >> >including >> >> the trust model between NAS nodes and access nodes." >> >> >> >> Regards, >> >> Woj. >> >> >> >> -----Original Message----- >> >> From: Busschbach, Peter B (Peter)=20 >[mailto:busschbach@lucent.com] >> >> Sent: 04 April 2006 21:23 >> >> To: 'l2cp@ietf.org' >> >> Subject: [L2CP] Re: Revised WG Charter Draft >> >> >> >> I have two comments on the revised charter. >> >> >> >> 1) At the end of the BOF, Mark=20 >Townsley limited >> the scope of the >> >> working group. Unfortunately, this is not captured very >> >clearly in the >> >> meeting minutes. The critical sentence in the=20 >meeting minutes is >> "DSL >> >> but good engineers ...". I.e. the focus of the WG is=20 >to solve a >> >> particular issue in DSL access networks, but as good >> >> engineers we should >> >> not preclude the use of the protocol for other applications. >> >> >> >> I don't see the limited scope reflected in the new charter. >> >> >> >> 2) Under "Line Configuration". the=20 >charter says: >> >> >> >> > L2CP is intended to simplify the OSS=20 >infrastructure for service >> >> > management, allowing subscriber-related service data to be >> >> maintained >> >> > in fewer repositories (e.g. RADIUS server back-end=20 >database) >> while >> >> > avoiding complex cross-organization interactions. >> >> >> >> I don't understand how L2CP leads to fewer Radius server >> >back end data >> >> bases. I also don't understand how L2CP avoids=20 >cross-organizational >> >> interactions. There seems to be an assumption that it is ok >> >> for L2CP to >> >> cross organizational boundaries but not for other=20 >protocols. I don't >> >> think that is correct. At the BOF, Dave Allan pointed out=20 >> >> that this is >> >> one of the more difficult problems to solve. Therefore, I >> >believe that >> >> this text should be removed from the charter. >> >> >> >> Peter >> >> >> >> >> >> >> >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F >> >> L2cp mailing list >> >> L2cp@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/l2cp >> >> >> > >> >=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >> >L2cp mailing list >> >L2cp@ietf.org >> >https://www1.ietf.org/mailman/listinfo/l2cp >> > >>=20 >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >> L2cp mailing list >> L2cp@ietf.org >> https://www1.ietf.org/mailman/listinfo/l2cp >>=20 >>=20 >>=20 >--------------------------------------------------------------- >--------- >>=20 >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F >> L2cp mailing list >> L2cp@ietf.org >> https://www1.ietf.org/mailman/listinfo/l2cp > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F L2cp mailing list L2cp@ietf.org https://www1.ietf.org/mailman/listinfo/l2cp --=_alternative 002B09ABC225717D_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Thomas, Sanjay,
How should we send information in the example Thomas gave?

Clear:
If we have on the same DSL port 2 en= capsulations on 2 different VLANs or VCs, then we should send
2 messages (each having a different ACI) - ACI in this case must include layer 1+ layer 2 identifiers.

Unclear:
Should we send Layer 1 information in both messages, in one of them, in a different message?

Regards,
Michel.

"Sanjay Wadhwa&q= uot; <swadhwa@juniper.net>

25/05/2006 15:53

To	"Haag, T" <Thomas.Haag@= t-systems.com>, <Michel.Platnic@ecitele.com>
cc	<l2cp@ietf.org>
Subject	RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation

Hi Thomas
The encapsulation is = reported per ACI. If the two encaps correspond to two different logical circuits (VLANs or VCs) on the same access line, then we should be able to appropria= tely report it for both ACIs and adjust the shaper on the BNG.

-Sanjay

-----Original Message-----
From: Haag, T [mailto:Thomas.Haag@t-systems.com]
Sent: Wednesday, May 24, 2006 7:47 AM
To: Michel.Platnic@ecitele.com; Sanjay Wadhwa
Cc: l2cp@ietf.org
Subject: AW: [L2CP] RE: Wadhwa new draft 01- Encapsulation

Hi Michel, Hi Sanjay, all= ,

First of all I agree to u= se already defined TLVs although it will not solve our basic problem of mixing layer 1 and 2 information.

To use a TLV for encapsul= ation adds another mixing. Imagine you have two different types (e.g. PPPoE + IPoE) of encapsulation at the same time at the local loop.

1. Does the model allow t= wo different types at the same time?
2. Should the DSLAM send = in upstream two different TLV’s?
3. Supposed the DSLAM sen= ds two TLV’s what should the BNG do with it?
4. How can you adjust a s= haper on that information?

I think these facts are n= ot solved by TR-101 too. So I have some concerns to follow TR-101 in that way and see some space for improvement.

Regards

Thomas
-----Urspr=FCngliche Nachricht----- Von: Michel.Platnic@ecitele.com [mailto:Michel.Platnic@ecitele.com]
Gesendet: Mittwoch, 24. Mai 2006 11:46
An: Sanjay Wadhwa
Cc: l2cp@ietf.org
Betreff: RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation

Hi Sanjay and all,
I support Sanjay's proposal to have this encapsulation transported by ANCP, even if we may argue that
we already have 2 protocols that may transport this information (DHCP and PPPoE).
About having a different TLV to transport the Encapsulation, it only partia= lly solves the problem of potentially mixing
layer 1 and layer 2 information. Actually the DSL forum (TR-101) uses same principle described in your document to transport this
information, it is probably wise to follow the same mechanism..
Unless other people share this concern, I'll go with your proposal.<= font size=3D3 face=3D"Times New Roman">
Best Regards,
Michel.

"Sanjay Wad= hwa" <swadhwa@juniper.net>
24/05/2006 00:01

To
<stefaan.de=5Fcn= odder@alcatel.be>

cc
l2cp@ietf.org

Subject
RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation + Remode Id comments

>-----Original Message-----
>From: stefaan.de=5Fcnodder@alcatel.be
>[mailto:stefaan.de=5Fcnodder@alcatel.be]
>Sent: Tuesday, May 23, 2006 1:07 PM
>To: Sanjay Wadhwa
>Cc: l2cp@ietf.org
>Subject: Re: [L2CP] RE: Wadhwa new draft 01- Encapsulation + Remode Id
>comments
>
>
>
>Hi Sanjay,
>
>>
>> - Why was the access loop encapsulation object inclu= ded within a
>> message where all parameters transmitted are layer 1 oriented?
>> There might be several encapsulations available per
>physical link, a
>> new message could maybe better serve the purpose of
>> transmitting the encapsulation parameters.
>> [[SW]] I have sympathy for your arguement as I had a similar
>> concern, which is why L2 encaps has been specified as a
>seprate and
>> optional TLV (although same message).
>> It is to an extent useful for the BNG to learn l2 encaps on the
>> local-loop as it can in some cases allow for more
>accurate shaping
>> of subscriber traffic.
>>
>
>Why not specifying the bandwidth at L2? Then the BNG just takes this
>bandwidth for shaping and it does not have to take care of what
>encapsulation has been used. Why bottering the BNG with the
>encap on the
>DSL line. And what if later someone wants to do the same on non-DSL
>access lines? Are we going to add encap types and updating the
>BNG with
>these new encap types to compute the correct shaping rate? I
>believe it
>would be better to specify the bandwidth at which the BNG has to shape.=

[SW] Shaping on the BNG (based on counting bytes transmitted) needs to
know the "byte adjustment" (under/over-head) due to difference in encaps
on the aggregation network and access loop. I suppose the access-node
could indicate the absolute difference in terms of bytes between the two
encapsulations.. however, this might not be accurate as an aggregation
switch upstream of the DSLAM could change the encaps (e.g. insert an
outer VLAN tag). Ideally, the BNG needs to use the difference between
it's encaps and the encaps on the local-loop. Also, the BNG needs to
adjust for cell-tax if the local-loop is cell based.

-Sanjay

>regards,
>Stefaan
>
>
>> *Chapter 5.4.2*
>> - Typo:
>> Type (Access-Loop-Circuit-ID =3D 0x01) : defined in section 5.4.1
>> Type (Access-Aggregation-Circuit-ID-Binary =3D 0x02): defined in
>> section 5.4.1.
>> Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03) : defined in
>> section 5.4.1.
>> These lines should be updated to comply to Chapter 5.4.1.
>>
>> [[SW]] Will fix.
>>
>> Thanks
>> -Sanjay
>>
>> Thanks and Best Regards,
>> Michel.
>>
>>
>>
>>
>> *"Sanjay Wadhwa" <swadhwa@juniper.net&g= t;*
>>
>> 05/04/2006 19:22
>>
>>
>> To
>> "Busschbach, Peter B \(Peter\)"
><busschbach@lucent.com>, "Wojciech
>> Dec \(wdec\)" <wdec@cisco.com>, <l2cp@= ietf.org>
>> cc
>>
>> Subject
>> RE: [L2CP] Advantages of L2CP (was: Revised WG Charter Draft)<= br> >>
>>
>>
>>
>>
>>
>>
>>
>> Peter
>> Please see inline..
>>
>> >-----Original Message-----
>> >From: Busschbach, Peter B (Peter)
>[mailto:busschbach@lucent.com]
>> >Sent: Wednesday, April 05, 2006 10:51 AM
>> >To: 'Wojciech Dec (wdec)'; l2cp@ietf.org >> >Subject: [L2CP] Advantages of L2CP (was: Revised WG
>Charter Draft)
>> >
>> >
>> >Hi Woj,
>> >
>> >To address the second half of our email exchange:
>> >
>> >I did notice the sentence that addressed Dave's concern.
>> >However, my point was that the charter claims that L2CP will
>> >have a specific benefit ("avoiding complex cross-organization
>> >interactions"), while it is far from clear that in this
>> >respect L2CP is any better than other solutions.
>>
>> [Sanjay] All that the charter is saying is that L2C work
>will undertake
>> use-cases that aim to simplify service management by
>avoiding complex
>> cross-organization interactions. It is a nobel goal that
>L2C is striving
>> to achieve.. What is wrong with that ? This is
>irrespective of wether
>> other solutions can provide this or not.
>> So, as an example, charter for a new dynamic routing
>protocol might say
>> that it will strive to achieve fast network-wide
>convergence (which is a
>> clear benefit over static routing). But, obviously it is
>ok for multiple
>> dynamic routing protocols to work towards this goal and have this
>> explicitly stated in their charter.
>>
>> -Sanjay
>>
>>
>> >I believe that the charter should avoid stating benefits that
>> >are debatable and therefore suggest that the text that I
>> >quoted in my first email be deleted from the charter.
>> >
>> >Peter
>> >
>> >> -----Original Message-----
>> >> From: Wojciech Dec (wdec) [mailto:wde= c@cisco.com]
>> >> Sent: Wednesday, April 05, 2006 7:34 AM
>> >> To: Busschbach, Peter B (Peter); l2cp@ietf.org
>> >> Subject: RE: [L2CP] Re: Revised WG Charter Draft
>> >>
>> >>
>> >> Hi Peter,
>> >>
>> >> To address 1) we have put in the following statement
>in the charter
>> >> which you may have not noticed.
>> >>
>> >> "The protocol design will not preclude other uses of L2CP."
>> >>
>> >> WRT 2) we do not lay any claims to how different
>operators structure
>> >> their data bases, and some are probab= ly better at doing it
>> >> than others.
>> >> However it does seem to be a fairly common problem that the
>> >> info related
>> >> to a single subscriber's network service needs to be farmed
>> >> out and fed
>> >> into numerous custom built manager systems besides also the
>> >Radius DB.
>> >> The idea is to allow a mechanism, through the use of L2CP,
>> >to have the
>> >> Access node be provided with such information as and when
>> >> needed by the
>> >> NAS which in turn accesses a common repository like
>a Radius DB.
>> >> Dave's statement was, I believe, in relation to different
>> >> subject; that
>> >> of a wholesale-retail operation, where indeed the
>> >relationship is more
>> >> complex. However we do plan on addres= sing this as
>evidenced by the
>> >> statement in the charter:
>> >> "L2CP will address security aspects of the control protocol,
>> >including
>> >> the trust model between NAS nodes and access nodes."
>> >>
>> >> Regards,
>> >> Woj.
>> >>
>> >> -----Original Message-----
>> >> From: Busschbach, Peter B (Peter)
>[mailto:busschbach@lucent.com]
>> >> Sent: 04 April 2006 21:23
>> >> To: 'l2cp@ietf.org'
>> >> Subject: [L2CP] Re: Revised WG Charter Draft
>> >>
>> >> I have two comments on the revised charter.
>> >>
>> >> 1) At the end of the BOF, Mark
>Townsley limited
>> the scope of the
>> >> working group. Unfortunately, this is not captured very
>> >clearly in the
>> >> meeting minutes. The critical sentence in the
>meeting minutes is
>> "DSL
>> >> but good engineers ...". I.e. the focus of the WG is
>to solve a
>> >> particular issue in DSL access networ= ks, but as good
>> >> engineers we should
>> >> not preclude the use of the protocol for other applications.
>> >>
>> >> I don't see the limited scope reflect= ed in the new charter.
>> >>
>> >> 2) Under "Line Configuration". the
>charter says:
>> >>
>> >> > L2CP is intended to simplify the OSS
>infrastructure for service
>> >> > management, allowing subscriber-= related service data to be
>> >> maintained
>> >> > in fewer repositories (e.g. RADIUS server back-end
>database)
>> while
>> >> > avoiding complex cross-organizat= ion interactions.
>> >>
>> >> I don't understand how L2CP leads to fewer Radius server
>> >back end data
>> >> bases. I also don't understand how L2CP avoids
>cross-organizational
>> >> interactions. There seems to be an assumption that it is ok
>> >> for L2CP to
>> >> cross organizational boundaries but not for other
>protocols. I don't
>> >> think that is correct. At the BOF, Dave Allan pointed out
>> >> that this is
>> >> one of the more difficult problems to solve. Therefore, I
>> >believe that
>> >> this text should be removed from the charter.
>> >>
>> >> Peter
>> >>
>> >>
>> >>
>> >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
>> >> L2cp mailing list
>> >> L2cp@ietf.org
>> >> https://www1.ietf.org/mailman/listinf= o/l2cp
>> >>
>> >
>> >=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F
>> >L2cp mailing list
>> >L2cp@ietf.org
>> >https://www1.ietf.org/mailman/listinfo/l2c= p
>> >
>>
>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F
>> L2cp mailing list
>> L2cp@ietf.org
>> https://www1.ietf.org/mailman/listinfo/l2cp
>>
>>
>>
>---------------------------------------------------------------
>---------
>>
>> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
>> L2cp mailing list
>> L2cp@ietf.org
>> https://www1.ietf.org/mailman/listinfo/l2cp
>

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
L2cp mailing list
L2cp@ietf.org
https://www1.ietf.org/mailman/listinfo/l2cp
--=_alternative 002B09ABC225717D_=-- --===============1342180152== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ L2cp mailing list L2cp@ietf.org https://www1.ietf.org/mailman/listinfo/l2cp --===============1342180152==-- From l2cp-bounces@ietf.org Mon May 29 08:10:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkgZk-0000Ku-4T; Mon, 29 May 2006 08:10:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkgZi-0000KZ-Hc for l2cp@ietf.org; Mon, 29 May 2006 08:10:22 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkgZd-000750-Ji for l2cp@ietf.org; Mon, 29 May 2006 08:10:22 -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 k4TCA1DR019346; Mon, 29 May 2006 14:10:12 +0200 Received: from [138.203.192.250] ([138.203.192.250]) by bemail06.netfr.alcatel.fr (Lotus Domino Release 5.0.12HF868) with ESMTP id 2006052914100118:2903 ; Mon, 29 May 2006 14:10:01 +0200 Message-ID: <447AE499.3050403@alcatel.be> Date: Mon, 29 May 2006 14:10:01 +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: Derek Harkness Subject: Re: [L2CP] RE: Wadhwa new draft 01- Encapsulation References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 05/29/2006 14:10:01, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 05/29/2006 14:10:11, Serialize complete at 05/29/2006 14:10:11 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: f460acdc4aacf7fc5e6f9bd32f8fd8c6 Cc: l2cp@ietf.org X-BeenThere: l2cp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Layer 2 Control Protocol Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: l2cp-bounces@ietf.org Hi Derek, see below Derek Harkness wrote: > > We have seen this from deployments using VDSL2 DSLAMs. My understanding > is that the overhead is due to the local loop framing which includes > FEC, trellis encoding and other factors. Possibly this can be derived > from the DSL type which we already have in the protocol - I am not > familiar enough with the details of all DSL encodings to be able to > judge that, maybe the access node experts could shed some light here ? > These physical layer overhead cannot be derived from the DSL type because trellis encoding for instance can be switched off or on. However, this overhead of the physical layer is already substracted from the physical bit rate when computing the actual bit rate so I guess there are no issue. regards, Stefaan > Cheers, > > Derek. > > > +=============================+ > Derek Harkness > Systems Engineer > Juniper Networks > Nymphenburger Strasse 13-15 > 80335 Munich > Germany > Tel: +49 89 5529 4916 > Mobile: +49 172 843 6621 > Email: DHarkness@juniper.net > +=============================+ > > > ------------------------------------------------------------------------ > *From:* Michel.Platnic@ecitele.com [mailto:Michel.Platnic@ecitele.com] > *Sent:* 24 May 2006 11:46 > *To:* Sanjay Wadhwa > *Cc:* l2cp@ietf.org > *Subject:* RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation > > > Hi Sanjay and all, > I support Sanjay's proposal to have this encapsulation transported by > ANCP, even if we may argue that > we already have 2 protocols that may transport this information (DHCP > and PPPoE). > About having a different TLV to transport the Encapsulation, it only > partially solves the problem of potentially mixing > layer 1 and layer 2 information. Actually the DSL forum (TR-101) uses > same principle described in your document to transport this > information, it is probably wise to follow the same mechanism.. > Unless other people share this concern, I'll go with your proposal. > Best Regards, > Michel. > > > > *"Sanjay Wadhwa" * > > 24/05/2006 00:01 > > > To > > cc > l2cp@ietf.org > Subject > RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation + Remode Id comments > > > > > > > > > > > >-----Original Message----- > >From: stefaan.de_cnodder@alcatel.be > >[mailto:stefaan.de_cnodder@alcatel.be] > >Sent: Tuesday, May 23, 2006 1:07 PM > >To: Sanjay Wadhwa > >Cc: l2cp@ietf.org > >Subject: Re: [L2CP] RE: Wadhwa new draft 01- Encapsulation + Remode Id > >comments > > > > > > > >Hi Sanjay, > > > >> > >> - Why was the access loop encapsulation object included within a > >> message where all parameters transmitted are layer 1 oriented? > >> There might be several encapsulations available per > >physical link, a > >> new message could maybe better serve the purpose of > >> transmitting the encapsulation parameters. > >> [[SW]] I have sympathy for your arguement as I had a similar > >> concern, which is why L2 encaps has been specified as a > >seprate and > >> optional TLV (although same message). > >> It is to an extent useful for the BNG to learn l2 encaps on the > >> local-loop as it can in some cases allow for more > >accurate shaping > >> of subscriber traffic. > >> > > > >Why not specifying the bandwidth at L2? Then the BNG just takes this > >bandwidth for shaping and it does not have to take care of what > >encapsulation has been used. Why bottering the BNG with the > >encap on the > >DSL line. And what if later someone wants to do the same on non-DSL > >access lines? Are we going to add encap types and updating the > >BNG with > >these new encap types to compute the correct shaping rate? I > >believe it > >would be better to specify the bandwidth at which the BNG has to shape. > > [SW] Shaping on the BNG (based on counting bytes transmitted) needs to > know the "byte adjustment" (under/over-head) due to difference in encaps > on the aggregation network and access loop. I suppose the access-node > could indicate the absolute difference in terms of bytes between the two > encapsulations.. however, this might not be accurate as an aggregation > switch upstream of the DSLAM could change the encaps (e.g. insert an > outer VLAN tag). Ideally, the BNG needs to use the difference between > it's encaps and the encaps on the local-loop. Also, the BNG needs to > adjust for cell-tax if the local-loop is cell based. > > -Sanjay > > > >regards, > >Stefaan > > > > > >> *Chapter 5.4.2* > >> - Typo: > >> Type (Access-Loop-Circuit-ID = 0x01) : defined in section 5.4.1 > >> Type (Access-Aggregation-Circuit-ID-Binary = 0x02): defined in > >> section 5.4.1. > >> Type (Access-Aggregation-Circuit-ID-ASCII = 0x03) : defined in > >> section 5.4.1. > >> These lines should be updated to comply to Chapter 5.4.1. > >> > >> [[SW]] Will fix. > >> > >> Thanks > >> -Sanjay > >> > >> Thanks and Best Regards, > >> Michel. > >> > >> > >> > >> > >> *"Sanjay Wadhwa" * > >> > >> 05/04/2006 19:22 > >> > >> > >> To > >> "Busschbach, Peter B \(Peter\)" > >, "Wojciech > >> Dec \(wdec\)" , > >> cc > >> > >> Subject > >> RE: [L2CP] Advantages of L2CP (was: Revised WG > Charter Draft) > >> > >> > >> > >> > >> > >> > >> > >> > >> Peter > >> Please see inline.. > >> > >> >-----Original Message----- > >> >From: Busschbach, Peter B (Peter) > >[mailto:busschbach@lucent.com] > >> >Sent: Wednesday, April 05, 2006 10:51 AM > >> >To: 'Wojciech Dec (wdec)'; l2cp@ietf.org > >> >Subject: [L2CP] Advantages of L2CP (was: Revised WG > >Charter Draft) > >> > > >> > > >> >Hi Woj, > >> > > >> >To address the second half of our email exchange: > >> > > >> >I did notice the sentence that addressed Dave's concern. > >> >However, my point was that the charter claims that L2CP will > >> >have a specific benefit ("avoiding complex cross-organization > >> >interactions"), while it is far from clear that in this > >> >respect L2CP is any better than other solutions. > >> > >> [Sanjay] All that the charter is saying is that L2C work > >will undertake > >> use-cases that aim to simplify service management by > >avoiding complex > >> cross-organization interactions. It is a nobel goal that > >L2C is striving > >> to achieve.. What is wrong with that ? This is > >irrespective of wether > >> other solutions can provide this or not. > >> So, as an example, charter for a new dynamic routing > >protocol might say > >> that it will strive to achieve fast network-wide > >convergence (which is a > >> clear benefit over static routing). But, obviously it is > >ok for multiple > >> dynamic routing protocols to work towards this goal and have this > >> explicitly stated in their charter. > >> > >> -Sanjay > >> > >> > >> >I believe that the charter should avoid stating benefits that > >> >are debatable and therefore suggest that the text that I > >> >quoted in my first email be deleted from the charter. > >> > > >> >Peter > >> > > >> >> -----Original Message----- > >> >> From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] > >> >> Sent: Wednesday, April 05, 2006 7:34 AM > >> >> To: Busschbach, Peter B (Peter); l2cp@ietf.org > >> >> Subject: RE: [L2CP] Re: Revised WG Charter Draft > >> >> > >> >> > >> >> Hi Peter, > >> >> > >> >> To address 1) we have put in the following statement > >in the charter > >> >> which you may have not noticed. > >> >> > >> >> "The protocol design will not preclude other uses of L2CP." > >> >> > >> >> WRT 2) we do not lay any claims to how different > >operators structure > >> >> their data bases, and some are probably better at doing it > >> >> than others. > >> >> However it does seem to be a fairly common problem that the > >> >> info related > >> >> to a single subscriber's network service needs to be farmed > >> >> out and fed > >> >> into numerous custom built manager systems besides also the > >> >Radius DB. > >> >> The idea is to allow a mechanism, through the use of L2CP, > >> >to have the > >> >> Access node be provided with such information as and when > >> >> needed by the > >> >> NAS which in turn accesses a common repository like > >a Radius DB. > >> >> Dave's statement was, I believe, in relation to different > >> >> subject; that > >> >> of a wholesale-retail operation, where indeed the > >> >relationship is more > >> >> complex. However we do plan on addressing this as > >evidenced by the > >> >> statement in the charter: > >> >> "L2CP will address security aspects of the control protocol, > >> >including > >> >> the trust model between NAS nodes and access nodes." > >> >> > >> >> Regards, > >> >> Woj. > >> >> > >> >> -----Original Message----- > >> >> From: Busschbach, Peter B (Peter) > >[mailto:busschbach@lucent.com] > >> >> Sent: 04 April 2006 21:23 > >> >> To: 'l2cp@ietf.org' > >> >> Subject: [L2CP] Re: Revised WG Charter Draft > >> >> > >> >> I have two comments on the revised charter. > >> >> > >> >> 1) At the end of the BOF, Mark > >Townsley limited > >> the scope of the > >> >> working group. Unfortunately, this is not captured very > >> >clearly in the > >> >> meeting minutes. The critical sentence in the > >meeting minutes is > >> "DSL > >> >> but good engineers ...". I.e. the focus of the WG is > >to solve a > >> >> particular issue in DSL access networks, but as good > >> >> engineers we should > >> >> not preclude the use of the protocol for other applications. > >> >> > >> >> I don't see the limited scope reflected in the new charter. > >> >> > >> >> 2) Under "Line Configuration". the > >charter says: > >> >> > >> >> > L2CP is intended to simplify the OSS > >infrastructure for service > >> >> > management, allowing subscriber-related service data to be > >> >> maintained > >> >> > in fewer repositories (e.g. RADIUS server back-end > >database) > >> while > >> >> > avoiding complex cross-organization interactions. > >> >> > >> >> I don't understand how L2CP leads to fewer Radius server > >> >back end data > >> >> bases. I also don't understand how L2CP avoids > >cross-organizational > >> >> interactions. There seems to be an assumption that it is ok > >> >> for L2CP to > >> >> cross organizational boundaries but not for other > >protocols. I don't > >> >> think that is correct. At the BOF, Dave Allan pointed out > >> >> that this is > >> >> one of the more difficult problems to solve. Therefore, I > >> >believe that > >> >> this text should be removed from the charter. > >> >> > >> >> Peter > >> >> > >> >> > >> >> > >> >> _______________________________________________ > >> >> L2cp mailing list > >> >> L2cp@ietf.org > >> >> https://www1.ietf.org/mailman/listinfo/l2cp > >> >> > >> > > >> >_______________________________________________ > >> >L2cp mailing list > >> >L2cp@ietf.org > >> >https://www1.ietf.org/mailman/listinfo/l2cp > >> > > >> > >> _______________________________________________ > >> L2cp mailing list > >> L2cp@ietf.org > >> https://www1.ietf.org/mailman/listinfo/l2cp > >> > >> > >> > >--------------------------------------------------------------- > >--------- > >> > >> _______________________________________________ > >> L2cp mailing list > >> L2cp@ietf.org > >> https://www1.ietf.org/mailman/listinfo/l2cp > > > > _______________________________________________ > L2cp mailing list > L2cp@ietf.org > https://www1.ietf.org/mailman/listinfo/l2cp > > > ------------------------------------------------------------------------ > > _______________________________________________ > L2cp mailing list > L2cp@ietf.org > https://www1.ietf.org/mailman/listinfo/l2cp _______________________________________________ L2cp mailing list L2cp@ietf.org https://www1.ietf.org/mailman/listinfo/l2cp From l2cp-bounces@ietf.org Mon May 29 17:57:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkpjl-0005fF-PJ; Mon, 29 May 2006 17:57:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkpjk-0005ey-G2 for l2cp@ietf.org; Mon, 29 May 2006 17:57:20 -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 1FkpFZ-0003c7-AJ for l2cp@ietf.org; Mon, 29 May 2006 17:26:09 -0400 Received: from prattle.redback.com ([155.53.12.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fkozx-0003Pm-U5 for l2cp@ietf.org; Mon, 29 May 2006 17:10:06 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id B1989A2FC8C for ; Mon, 29 May 2006 14:09:57 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19131-07 for ; Mon, 29 May 2006 14:09:57 -0700 (PDT) Received: from [127.0.0.1] (login004.redback.com [155.53.12.57]) by prattle.redback.com (Postfix) with ESMTP id 3A6FBA2FC8B for ; Mon, 29 May 2006 14:09:57 -0700 (PDT) Message-ID: <447B6359.5040100@redback.com> Date: Mon, 29 May 2006 14:10:49 -0700 From: Jakob Heitz Organization: Redback Networks, Software Development User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: l2cp@ietf.org Subject: Re: [L2CP] RE: Wadhwa new draft 01- Encapsulation References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed X-Virus-Scanned: by amavisd-new at redback.com Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.6 (--) X-Scan-Signature: 14278aea5bdd1edf35ec09ffb7b61f9d X-BeenThere: l2cp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Layer 2 Control Protocol Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: l2cp-bounces@ietf.org Several virtual circuits can share an access loop. If we enhance the meaning of an ACI to identify a virtual circuit on an access loop, rather than just the access loop, then an access loop can carry several ACIs. Does that mean that all the ACIs on one access loop can share the bandwidth of that access loop? If the bandwidth is that of the access loop, not that of the virtual circuit, how is the BRAS to know which ACIs belong to the same access loop? The bandwidth belongs to the access loop. The encapsulation belongs to the virtual circuit. We have a concept of an access loop and an identifier for it: Access-Loop-Circuit-ID. Do we need a concept of a virtual circuit (on an access loop) and a new identifier for it? Or do we need to add a hierarchy of ACIs and a way to communicate the structure of the hierarchy, ie, which "inner" ACIs (virtual circuit) belong to which "outer" ACIs (access loop)? Michel.Platnic@ecitele.com wrote: >=20 > Hi Thomas, Sanjay, > How should we send information in the example Thomas gave? >=20 > Clear: > If we have on the same DSL port 2 encapsulations on 2 different VLANs o= r=20 > VCs, then we should send > 2 messages (each having a different ACI) - ACI in this case must includ= e=20 > layer 1+ layer 2 identifiers. >=20 > Unclear: > Should we send Layer 1 information in both messages, in one of them, in= =20 > a different message? >=20 > Regards, > Michel. >=20 >=20 >=20 > *"Sanjay Wadhwa" * >=20 > 25/05/2006 15:53 >=20 > =09 > To > "Haag, T" , > cc > > Subject > RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation >=20 >=20 > =09 >=20 >=20 >=20 >=20 >=20 > Hi Thomas > The encapsulation is reported per ACI. If the two encaps correspond t= o=20 > two different logical circuits (VLANs or VCs) on the same access line,=20 > then we should be able to appropriately report it for both ACIs and=20 > adjust the shaper on the BNG. > =20 > -Sanjay > =20 > -----Original Message-----* > From:* Haag, T [mailto:Thomas.Haag@t-systems.com]* > Sent:* Wednesday, May 24, 2006 7:47 AM* > To:* Michel.Platnic@ecitele.com; Sanjay Wadhwa* > Cc:* l2cp@ietf.org* > Subject:* AW: [L2CP] RE: Wadhwa new draft 01- Encapsulation >=20 > Hi Michel, Hi Sanjay, all, > =20 > First of all I agree to use already defined TLVs although it will not=20 > solve our basic problem of mixing layer 1 and 2 information. > =20 > To use a TLV for encapsulation adds another mixing. Imagine you have tw= o=20 > different types (e.g. PPPoE + IPoE) of encapsulation at the same time a= t=20 > the local loop. > =20 > 1. Does the model allow two different types at the same time? > 2. Should the DSLAM send in upstream two different TLV=92s? > 3. Supposed the DSLAM sends two TLV=92s what should the BNG do with it? > 4. How can you adjust a shaper on that information? > =20 > I think these facts are not solved by TR-101 too. So I have some=20 > concerns to follow TR-101 in that way and see some space for improvemen= t. > =20 >=20 > *Regards* >=20 > *Thomas* > -----Urspr=FCngliche Nachricht-----* > Von:* Michel.Platnic@ecitele.com [mailto:Michel.Platnic@ecitele.com] * > Gesendet:* Mittwoch, 24. Mai 2006 11:46* > An:* Sanjay Wadhwa* > Cc:* l2cp@ietf.org* > Betreff:* RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation > =20 >=20 > Hi Sanjay and all, > I support Sanjay's proposal to have this encapsulation transported by=20 > ANCP, even if we may argue that > we already have 2 protocols that may transport this information (DHCP=20 > and PPPoE). > About having a different TLV to transport the Encapsulation, it only=20 > partially solves the problem of potentially mixing > layer 1 and layer 2 information. Actually the DSL forum (TR-101) uses=20 > same principle described in your document to transport this > information, it is probably wise to follow the same mechanism.. > Unless other people share this concern, I'll go with your proposal. > Best Regards, > Michel. >=20 > *"Sanjay Wadhwa" * >=20 > 24/05/2006 00:01 >=20 > =09 > To > > cc > l2cp@ietf.org > Subject > RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation + Remode Id comments >=20 >=20 > =20 >=20 >=20 > =20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > >-----Original Message----- > >From: stefaan.de_cnodder@alcatel.be > >[mailto:stefaan.de_cnodder@alcatel.be] > >Sent: Tuesday, May 23, 2006 1:07 PM > >To: Sanjay Wadhwa > >Cc: l2cp@ietf.org > >Subject: Re: [L2CP] RE: Wadhwa new draft 01- Encapsulation + Remode I= d > >comments > > > > > > > >Hi Sanjay, > > > >> > >> - Why was the access loop encapsulation object included within = a > >> message where all parameters transmitted are layer 1 oriented? > >> There might be several encapsulations available per > >physical link, a > >> new message could maybe better serve the purpose of > >> transmitting the encapsulation parameters. > >> [[SW]] I have sympathy for your arguement as I had a similar > >> concern, which is why L2 encaps has been specified as a > >seprate and > >> optional TLV (although same message). > >> It is to an extent useful for the BNG to learn l2 encaps on the > >> local-loop as it can in some cases allow for more > >accurate shaping > >> of subscriber traffic. > >> > > > >Why not specifying the bandwidth at L2? Then the BNG just takes this > >bandwidth for shaping and it does not have to take care of what > >encapsulation has been used. Why bottering the BNG with the > >encap on the > >DSL line. And what if later someone wants to do the same on non-DSL > >access lines? Are we going to add encap types and updating the > >BNG with > >these new encap types to compute the correct shaping rate? I > >believe it > >would be better to specify the bandwidth at which the BNG has to shap= e. >=20 > [SW] Shaping on the BNG (based on counting bytes transmitted) needs to > know the "byte adjustment" (under/over-head) due to difference in encap= s > on the aggregation network and access loop. I suppose the access-node > could indicate the absolute difference in terms of bytes between the tw= o > encapsulations.. however, this might not be accurate as an aggregation > switch upstream of the DSLAM could change the encaps (e.g. insert an > outer VLAN tag). Ideally, the BNG needs to use the difference between > it's encaps and the encaps on the local-loop. Also, the BNG needs to > adjust for cell-tax if the local-loop is cell based. >=20 > -Sanjay >=20 >=20 > >regards, > >Stefaan > > > > > >> *Chapter 5.4.2* > >> - Typo: > >> Type (Access-Loop-Circuit-ID =3D 0x01) : defined in section 5.4= .1 > >> Type (Access-Aggregation-Circuit-ID-Binary =3D 0x02): defined i= n > >> section 5.4.1. =20 > >> Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03) : defined i= n > >> section 5.4.1. =20 > >> These lines should be updated to comply to Chapter 5.4.1. > >> > >> [[SW]] Will fix. > >> =20 > >> Thanks > >> -Sanjay > >> > >> Thanks and Best Regards, > >> Michel. > >> > >> > >> > >> > >> *"Sanjay Wadhwa" * > >> > >> 05/04/2006 19:22 > >> > >> =20 > >> To > >> "Busschbach, Peter B \(Peter\)" > >, "Wojciech > >> Dec \(wdec\)" , > >> cc > >> =20 > >> Subject > >> RE: [L2CP] Advantages of L2CP (was: Revised WG= =20 > Charter Draft) > >> > >> > >> =20 > >> > >> > >> > >> > >> > >> Peter > >> Please see inline.. > >> > >> >-----Original Message----- > >> >From: Busschbach, Peter B (Peter) > >[mailto:busschbach@lucent.com] > >> >Sent: Wednesday, April 05, 2006 10:51 AM > >> >To: 'Wojciech Dec (wdec)'; l2cp@ietf.org > >> >Subject: [L2CP] Advantages of L2CP (was: Revised WG > >Charter Draft) > >> > > >> > > >> >Hi Woj, > >> > > >> >To address the second half of our email exchange: > >> > > >> >I did notice the sentence that addressed Dave's concern. > >> >However, my point was that the charter claims that L2CP will > >> >have a specific benefit ("avoiding complex cross-organization > >> >interactions"), while it is far from clear that in this > >> >respect L2CP is any better than other solutions. > >> > >> [Sanjay] All that the charter is saying is that L2C work > >will undertake > >> use-cases that aim to simplify service management by > >avoiding complex > >> cross-organization interactions. It is a nobel goal that > >L2C is striving > >> to achieve.. What is wrong with that ? This is > >irrespective of wether > >> other solutions can provide this or not. > >> So, as an example, charter for a new dynamic routing > >protocol might say > >> that it will strive to achieve fast network-wide > >convergence (which is a > >> clear benefit over static routing). But, obviously it is > >ok for multiple > >> dynamic routing protocols to work towards this goal and have th= is > >> explicitly stated in their charter. > >> > >> -Sanjay > >> > >> > >> >I believe that the charter should avoid stating benefits that > >> >are debatable and therefore suggest that the text that I > >> >quoted in my first email be deleted from the charter. > >> > > >> >Peter > >> > > >> >> -----Original Message----- > >> >> From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] > >> >> Sent: Wednesday, April 05, 2006 7:34 AM > >> >> To: Busschbach, Peter B (Peter); l2cp@ietf.org > >> >> Subject: RE: [L2CP] Re: Revised WG Charter Draft > >> >> > >> >> > >> >> Hi Peter, > >> >> > >> >> To address 1) we have put in the following statement > >in the charter > >> >> which you may have not noticed. > >> >> > >> >> "The protocol design will not preclude other uses of L2CP." > >> >> > >> >> WRT 2) we do not lay any claims to how different > >operators structure > >> >> their data bases, and some are probably better at doing it > >> >> than others. > >> >> However it does seem to be a fairly common problem that the > >> >> info related > >> >> to a single subscriber's network service needs to be farmed > >> >> out and fed > >> >> into numerous custom built manager systems besides also the > >> >Radius DB. > >> >> The idea is to allow a mechanism, through the use of L2CP, > >> >to have the > >> >> Access node be provided with such information as and when > >> >> needed by the > >> >> NAS which in turn accesses a common repository like > >a Radius DB. > >> >> Dave's statement was, I believe, in relation to different > >> >> subject; that > >> >> of a wholesale-retail operation, where indeed the > >> >relationship is more > >> >> complex. However we do plan on addressing this as > >evidenced by the > >> >> statement in the charter: > >> >> "L2CP will address security aspects of the control protocol= , > >> >including > >> >> the trust model between NAS nodes and access nodes." > >> >> > >> >> Regards, > >> >> Woj. > >> >> > >> >> -----Original Message----- > >> >> From: Busschbach, Peter B (Peter) > >[mailto:busschbach@lucent.com] > >> >> Sent: 04 April 2006 21:23 > >> >> To: 'l2cp@ietf.org' > >> >> Subject: [L2CP] Re: Revised WG Charter Draft > >> >> > >> >> I have two comments on the revised charter. > >> >> > >> >> 1) At the end of the BOF, Mark > >Townsley limited > >> the scope of the > >> >> working group. Unfortunately, this is not captured very > >> >clearly in the > >> >> meeting minutes. The critical sentence in the > >meeting minutes is > >> "DSL > >> >> but good engineers ...". I.e. the focus of the WG is > >to solve a > >> >> particular issue in DSL access networks, but as good > >> >> engineers we should > >> >> not preclude the use of the protocol for other applications= . > >> >> > >> >> I don't see the limited scope reflected in the new charter. > >> >> > >> >> 2) Under "Line Configuration". the > >charter says: > >> >> > >> >> > L2CP is intended to simplify the OSS > >infrastructure for service > >> >> > management, allowing subscriber-related service data to b= e > >> >> maintained > >> >> > in fewer repositories (e.g. RADIUS server back-end > >database) > >> while > >> >> > avoiding complex cross-organization interactions. > >> >> > >> >> I don't understand how L2CP leads to fewer Radius server > >> >back end data > >> >> bases. I also don't understand how L2CP avoids > >cross-organizational > >> >> interactions. There seems to be an assumption that it is ok > >> >> for L2CP to > >> >> cross organizational boundaries but not for other > >protocols. I don't > >> >> think that is correct. At the BOF, Dave Allan pointed out =20 > >> >> that this is > >> >> one of the more difficult problems to solve. Therefore, I > >> >believe that > >> >> this text should be removed from the charter. > >> >> > >> >> Peter --=20 Jakob Heitz. _______________________________________________ L2cp mailing list L2cp@ietf.org https://www1.ietf.org/mailman/listinfo/l2cp From l2cp-bounces@ietf.org Tue May 30 03:49:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkyyW-0000ud-Tk; Tue, 30 May 2006 03:49:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkyyW-0000uY-2S for l2cp@ietf.org; Tue, 30 May 2006 03:49:12 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkyyR-0004qF-4Z for l2cp@ietf.org; Tue, 30 May 2006 03:49:12 -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 k4U7n4bU009963; Tue, 30 May 2006 09:49:04 +0200 Received: from [138.203.192.250] ([138.203.192.250]) by bemail06.netfr.alcatel.fr (Lotus Domino Release 5.0.12HF868) with ESMTP id 2006053009490301:1410 ; Tue, 30 May 2006 09:49:03 +0200 Message-ID: <447BF8EE.1040104@alcatel.be> Date: Tue, 30 May 2006 09:49:02 +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: Jakob Heitz Subject: Re: [L2CP] RE: Wadhwa new draft 01- Encapsulation References: <447B6359.5040100@redback.com> In-Reply-To: <447B6359.5040100@redback.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 05/30/2006 09:49:03, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 05/30/2006 09:49:04 X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.3 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Cc: l2cp@ietf.org X-BeenThere: l2cp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Layer 2 Control Protocol Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1375103526==" Errors-To: l2cp-bounces@ietf.org --===============1375103526== Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: base64 DQoNCj4gDQo+IFRoZSBiYW5kd2lkdGggYmVsb25ncyB0byB0aGUgYWNjZXNzIGxvb3AuDQo+IFRo ZSBlbmNhcHN1bGF0aW9uIGJlbG9uZ3MgdG8gdGhlIHZpcnR1YWwgY2lyY3VpdC4NCj4gDQo+IFdl IGhhdmUgYSBjb25jZXB0IG9mIGFuIGFjY2VzcyBsb29wIGFuZCBhbiBpZGVudGlmaWVyDQo+IGZv ciBpdDogQWNjZXNzLUxvb3AtQ2lyY3VpdC1JRC4NCj4gDQo+IERvIHdlIG5lZWQgYSBjb25jZXB0 IG9mIGEgdmlydHVhbCBjaXJjdWl0IChvbiBhbg0KPiBhY2Nlc3MgbG9vcCkgYW5kIGEgbmV3IGlk ZW50aWZpZXIgZm9yIGl0Pw0KPiANCg0KU2luY2UgdGhlIEFjY2Vzcy1Mb29wLUNpcmN1aXQtSUQg bWF5IGNvbnRhaW4gdGhlIHZsYW4gb3IgdnBpLnZjaSwgMiANCnZpcnR1YWwgY2lyY3VpdHMgb24g dGhlIHNhbWUgRFNMIGxpbmUgbWF5IGhhdmUgZGlmZmVyZW50IA0KQWNjZXNzLUxvb3AtQ2lyY3Vp dC1JRHMuIEl0IGxvb2tzIHRvIG1lIHRoYXQgd2UgYWxyZWFkeSBoYXZlIGEgdmlydHVhbCANCmNp cmN1aXQgaWQgYnV0IHRoYXQgdGhlIHJlYWwgbG9vcCBpZCBpcyBtaXNzaW5nLi4uLi4NCg0KSWYg dGhlIHN0cmluZyBpbiB0aGUgQWNjZXNzLUxvb3AtQ2lyY3VpdC1JRCBNVVNUIGZvbGxvdyB0aGUg Zm9ybWF0IGFzIA0KZGVzY3JpYmVkIGluIHRoZSBkcmFmdCB3aXRoIHNsb3QvcG9ydDp2cGkudmNp IHRoZW4gaXQgYWxyZWFkeSBjb250YWlucyANCmJvdGggdGhlIGFjY2VzcyBsb29wIGFuZCB2aXJ0 dWFsIGNpcmN1aXQgYW5kIG5vdGhpbmcgbmV3IGlzIG5lZWRlZC4gDQpIb3dldmVyIHRoZSBkcmFm dCBzYXlzIHRoYXQgdGhpcyBpcyBqdXN0IGEgInR5cGljYWwgZm9ybWF0Ii4NCg0KcmVnYXJkcywN ClN0ZWZhYW4NCg0KPiBPciBkbyB3ZSBuZWVkIHRvIGFkZCBhIGhpZXJhcmNoeSBvZiBBQ0lzIGFu ZCBhIHdheQ0KPiB0byBjb21tdW5pY2F0ZSB0aGUgc3RydWN0dXJlIG9mIHRoZSBoaWVyYXJjaHks IGllLA0KPiB3aGljaCAiaW5uZXIiIEFDSXMgKHZpcnR1YWwgY2lyY3VpdCkgYmVsb25nIHRvDQo+ IHdoaWNoICJvdXRlciIgQUNJcyAoYWNjZXNzIGxvb3ApPw0KPiANCj4gTWljaGVsLlBsYXRuaWNA ZWNpdGVsZS5jb20gd3JvdGU6DQo+IA0KPj4NCj4+IEhpIFRob21hcywgU2FuamF5LA0KPj4gSG93 IHNob3VsZCB3ZSBzZW5kIGluZm9ybWF0aW9uIGluIHRoZSBleGFtcGxlIFRob21hcyBnYXZlPw0K Pj4NCj4+IENsZWFyOg0KPj4gSWYgd2UgaGF2ZSBvbiB0aGUgc2FtZSBEU0wgcG9ydCAyIGVuY2Fw c3VsYXRpb25zIG9uIDIgZGlmZmVyZW50IFZMQU5zIA0KPj4gb3IgVkNzLCB0aGVuIHdlIHNob3Vs ZCBzZW5kDQo+PiAyIG1lc3NhZ2VzIChlYWNoIGhhdmluZyBhIGRpZmZlcmVudCBBQ0kpIC0gQUNJ IGluIHRoaXMgY2FzZSBtdXN0IA0KPj4gaW5jbHVkZSBsYXllciAxKyBsYXllciAyIGlkZW50aWZp ZXJzLg0KPj4NCj4+IFVuY2xlYXI6DQo+PiBTaG91bGQgd2Ugc2VuZCBMYXllciAxIGluZm9ybWF0 aW9uIGluIGJvdGggbWVzc2FnZXMsIGluIG9uZSBvZiB0aGVtLCANCj4+IGluIGEgZGlmZmVyZW50 IG1lc3NhZ2U/DQo+Pg0KPj4gUmVnYXJkcywNCj4+IE1pY2hlbC4NCj4+DQo+Pg0KPj4NCj4+ICoi U2FuamF5IFdhZGh3YSIgPHN3YWRod2FAanVuaXBlci5uZXQ+Kg0KPj4NCj4+IDI1LzA1LzIwMDYg MTU6NTMNCj4+DQo+PiAgICAgDQo+PiBUbw0KPj4gICAgICJIYWFnLCBUIiA8VGhvbWFzLkhhYWdA dC1zeXN0ZW1zLmNvbT4sIDxNaWNoZWwuUGxhdG5pY0BlY2l0ZWxlLmNvbT4NCj4+IGNjDQo+PiAg ICAgPGwyY3BAaWV0Zi5vcmc+DQo+PiBTdWJqZWN0DQo+PiAgICAgUkU6IFtMMkNQXSBSRTogV2Fk aHdhIG5ldyBkcmFmdCAwMS0gRW5jYXBzdWxhdGlvbg0KPj4NCj4+DQo+PiAgICAgDQo+Pg0KPj4N Cj4+DQo+Pg0KPj4NCj4+IEhpIFRob21hcw0KPj4gICBUaGUgZW5jYXBzdWxhdGlvbiBpcyByZXBv cnRlZCBwZXIgQUNJLiBJZiB0aGUgdHdvIGVuY2FwcyBjb3JyZXNwb25kIA0KPj4gdG8gdHdvIGRp ZmZlcmVudCBsb2dpY2FsIGNpcmN1aXRzIChWTEFOcyBvciBWQ3MpIG9uIHRoZSBzYW1lIGFjY2Vz cyANCj4+IGxpbmUsIHRoZW4gd2Ugc2hvdWxkIGJlIGFibGUgdG8gYXBwcm9wcmlhdGVseSByZXBv cnQgaXQgZm9yIGJvdGggQUNJcyANCj4+IGFuZCBhZGp1c3QgdGhlIHNoYXBlciBvbiB0aGUgQk5H Lg0KPj4gIA0KPj4gLVNhbmpheQ0KPj4gIA0KPj4gIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t Kg0KPj4gRnJvbToqIEhhYWcsIFQgW21haWx0bzpUaG9tYXMuSGFhZ0B0LXN5c3RlbXMuY29tXSoN Cj4+IFNlbnQ6KiBXZWRuZXNkYXksIE1heSAyNCwgMjAwNiA3OjQ3IEFNKg0KPj4gVG86KiBNaWNo ZWwuUGxhdG5pY0BlY2l0ZWxlLmNvbTsgU2FuamF5IFdhZGh3YSoNCj4+IENjOiogbDJjcEBpZXRm Lm9yZyoNCj4+IFN1YmplY3Q6KiBBVzogW0wyQ1BdIFJFOiBXYWRod2EgbmV3IGRyYWZ0IDAxLSBF bmNhcHN1bGF0aW9uDQo+Pg0KPj4gSGkgTWljaGVsLCBIaSBTYW5qYXksIGFsbCwNCj4+ICANCj4+ IEZpcnN0IG9mIGFsbCBJIGFncmVlIHRvIHVzZSBhbHJlYWR5IGRlZmluZWQgVExWcyBhbHRob3Vn aCBpdCB3aWxsIG5vdCANCj4+IHNvbHZlIG91ciBiYXNpYyBwcm9ibGVtIG9mIG1peGluZyBsYXll ciAxIGFuZCAyIGluZm9ybWF0aW9uLg0KPj4gIA0KPj4gVG8gdXNlIGEgVExWIGZvciBlbmNhcHN1 bGF0aW9uIGFkZHMgYW5vdGhlciBtaXhpbmcuIEltYWdpbmUgeW91IGhhdmUgDQo+PiB0d28gZGlm ZmVyZW50IHR5cGVzIChlLmcuIFBQUG9FICsgSVBvRSkgb2YgZW5jYXBzdWxhdGlvbiBhdCB0aGUg c2FtZSANCj4+IHRpbWUgYXQgdGhlIGxvY2FsIGxvb3AuDQo+PiAgDQo+PiAxLiBEb2VzIHRoZSBt b2RlbCBhbGxvdyB0d28gZGlmZmVyZW50IHR5cGVzIGF0IHRoZSBzYW1lIHRpbWU/DQo+PiAyLiBT aG91bGQgdGhlIERTTEFNIHNlbmQgaW4gdXBzdHJlYW0gdHdvIGRpZmZlcmVudCBUTFaScz8NCj4+ IDMuIFN1cHBvc2VkIHRoZSBEU0xBTSBzZW5kcyB0d28gVExWknMgd2hhdCBzaG91bGQgdGhlIEJO RyBkbyB3aXRoIGl0Pw0KPj4gNC4gSG93IGNhbiB5b3UgYWRqdXN0IGEgc2hhcGVyIG9uIHRoYXQg aW5mb3JtYXRpb24/DQo+PiAgDQo+PiBJIHRoaW5rIHRoZXNlIGZhY3RzIGFyZSBub3Qgc29sdmVk IGJ5IFRSLTEwMSB0b28uIFNvIEkgaGF2ZSBzb21lIA0KPj4gY29uY2VybnMgdG8gZm9sbG93IFRS LTEwMSBpbiB0aGF0IHdheSBhbmQgc2VlIHNvbWUgc3BhY2UgZm9yIGltcHJvdmVtZW50Lg0KPj4g IA0KPj4NCj4+ICpSZWdhcmRzKg0KPj4NCj4+ICpUaG9tYXMqDQo+PiAtLS0tLVVyc3By/G5nbGlj aGUgTmFjaHJpY2h0LS0tLS0qDQo+PiBWb246KiBNaWNoZWwuUGxhdG5pY0BlY2l0ZWxlLmNvbSBb bWFpbHRvOk1pY2hlbC5QbGF0bmljQGVjaXRlbGUuY29tXSAqDQo+PiBHZXNlbmRldDoqIE1pdHR3 b2NoLCAyNC4gTWFpIDIwMDYgMTE6NDYqDQo+PiBBbjoqIFNhbmpheSBXYWRod2EqDQo+PiBDYzoq IGwyY3BAaWV0Zi5vcmcqDQo+PiBCZXRyZWZmOiogUkU6IFtMMkNQXSBSRTogV2FkaHdhIG5ldyBk cmFmdCAwMS0gRW5jYXBzdWxhdGlvbg0KPj4gIA0KPj4NCj4+IEhpIFNhbmpheSBhbmQgYWxsLA0K Pj4gSSBzdXBwb3J0IFNhbmpheSdzIHByb3Bvc2FsIHRvIGhhdmUgdGhpcyBlbmNhcHN1bGF0aW9u IHRyYW5zcG9ydGVkIGJ5IA0KPj4gQU5DUCwgZXZlbiBpZiB3ZSBtYXkgYXJndWUgdGhhdA0KPj4g d2UgYWxyZWFkeSBoYXZlIDIgcHJvdG9jb2xzIHRoYXQgbWF5IHRyYW5zcG9ydCB0aGlzIGluZm9y bWF0aW9uIChESENQIA0KPj4gYW5kIFBQUG9FKS4NCj4+IEFib3V0IGhhdmluZyBhIGRpZmZlcmVu dCBUTFYgdG8gdHJhbnNwb3J0IHRoZSBFbmNhcHN1bGF0aW9uLCBpdCBvbmx5IA0KPj4gcGFydGlh bGx5IHNvbHZlcyB0aGUgcHJvYmxlbSBvZiBwb3RlbnRpYWxseSBtaXhpbmcNCj4+IGxheWVyIDEg YW5kIGxheWVyIDIgaW5mb3JtYXRpb24uIEFjdHVhbGx5IHRoZSBEU0wgZm9ydW0gKFRSLTEwMSkg dXNlcyANCj4+IHNhbWUgcHJpbmNpcGxlIGRlc2NyaWJlZCBpbiB5b3VyIGRvY3VtZW50IHRvIHRy YW5zcG9ydCB0aGlzDQo+PiBpbmZvcm1hdGlvbiwgaXQgaXMgcHJvYmFibHkgd2lzZSB0byBmb2xs b3cgdGhlIHNhbWUgbWVjaGFuaXNtLi4NCj4+IFVubGVzcyBvdGhlciBwZW9wbGUgc2hhcmUgdGhp cyBjb25jZXJuLCBJJ2xsIGdvIHdpdGggeW91ciBwcm9wb3NhbC4NCj4+IEJlc3QgUmVnYXJkcywN Cj4+IE1pY2hlbC4NCj4+DQo+PiAqIlNhbmpheSBXYWRod2EiIDxzd2FkaHdhQGp1bmlwZXIubmV0 PioNCj4+DQo+PiAyNC8wNS8yMDA2IDAwOjAxDQo+Pg0KPj4gICAgIA0KPj4gVG8NCj4+ICAgICA8 c3RlZmFhbi5kZV9jbm9kZGVyQGFsY2F0ZWwuYmU+DQo+PiBjYw0KPj4gICAgIGwyY3BAaWV0Zi5v cmcNCj4+IFN1YmplY3QNCj4+ICAgICBSRTogW0wyQ1BdIFJFOiBXYWRod2EgbmV3IGRyYWZ0IDAx LSBFbmNhcHN1bGF0aW9uICsgUmVtb2RlIElkIA0KPj4gY29tbWVudHMNCj4+DQo+Pg0KPj4gIA0K Pj4NCj4+DQo+PiAgICAgICANCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+PiAgPi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiAgPkZyb206IHN0ZWZhYW4uZGVfY25vZGRlckBhbGNh dGVsLmJlDQo+PiAgPlttYWlsdG86c3RlZmFhbi5kZV9jbm9kZGVyQGFsY2F0ZWwuYmVdDQo+PiAg PlNlbnQ6IFR1ZXNkYXksIE1heSAyMywgMjAwNiAxOjA3IFBNDQo+PiAgPlRvOiBTYW5qYXkgV2Fk aHdhDQo+PiAgPkNjOiBsMmNwQGlldGYub3JnDQo+PiAgPlN1YmplY3Q6IFJlOiBbTDJDUF0gUkU6 IFdhZGh3YSBuZXcgZHJhZnQgMDEtIEVuY2Fwc3VsYXRpb24gKyBSZW1vZGUgSWQNCj4+ICA+Y29t bWVudHMNCj4+ICA+DQo+PiAgPg0KPj4gID4NCj4+ICA+SGkgU2FuamF5LA0KPj4gID4NCj4+ICA+ Pg0KPj4gID4+ICAgICAtIFdoeSB3YXMgdGhlIGFjY2VzcyBsb29wIGVuY2Fwc3VsYXRpb24gb2Jq ZWN0IGluY2x1ZGVkIHdpdGhpbiBhDQo+PiAgPj4gICAgIG1lc3NhZ2Ugd2hlcmUgYWxsIHBhcmFt ZXRlcnMgdHJhbnNtaXR0ZWQgYXJlIGxheWVyIDEgb3JpZW50ZWQ/DQo+PiAgPj4gICAgIFRoZXJl IG1pZ2h0IGJlIHNldmVyYWwgZW5jYXBzdWxhdGlvbnMgYXZhaWxhYmxlIHBlcg0KPj4gID5waHlz aWNhbCBsaW5rLCBhDQo+PiAgPj4gICAgIG5ldyBtZXNzYWdlIGNvdWxkIG1heWJlIGJldHRlciBz ZXJ2ZSB0aGUgcHVycG9zZSBvZg0KPj4gID4+ICAgICB0cmFuc21pdHRpbmcgdGhlIGVuY2Fwc3Vs YXRpb24gcGFyYW1ldGVycy4NCj4+ICA+PiAgICAgW1tTV11dIEkgaGF2ZSBzeW1wYXRoeSBmb3Ig eW91ciBhcmd1ZW1lbnQgYXMgSSBoYWQgYSBzaW1pbGFyDQo+PiAgPj4gICAgIGNvbmNlcm4sIHdo aWNoIGlzIHdoeSBMMiBlbmNhcHMgaGFzIGJlZW4gc3BlY2lmaWVkIGFzIGENCj4+ICA+c2VwcmF0 ZSBhbmQNCj4+ICA+PiAgICAgb3B0aW9uYWwgVExWIChhbHRob3VnaCBzYW1lIG1lc3NhZ2UpLg0K Pj4gID4+ICAgICBJdCBpcyB0byBhbiBleHRlbnQgdXNlZnVsIGZvciB0aGUgQk5HIHRvIGxlYXJu IGwyIGVuY2FwcyBvbiB0aGUNCj4+ICA+PiAgICAgbG9jYWwtbG9vcCBhcyBpdCBjYW4gaW4gc29t ZSBjYXNlcyBhbGxvdyBmb3IgbW9yZQ0KPj4gID5hY2N1cmF0ZSBzaGFwaW5nDQo+PiAgPj4gICAg IG9mIHN1YnNjcmliZXIgdHJhZmZpYy4NCj4+ICA+Pg0KPj4gID4NCj4+ICA+V2h5IG5vdCBzcGVj aWZ5aW5nIHRoZSBiYW5kd2lkdGggYXQgTDI/IFRoZW4gdGhlIEJORyBqdXN0IHRha2VzIHRoaXMN Cj4+ICA+YmFuZHdpZHRoIGZvciBzaGFwaW5nIGFuZCBpdCBkb2VzIG5vdCBoYXZlIHRvIHRha2Ug Y2FyZSBvZiB3aGF0DQo+PiAgPmVuY2Fwc3VsYXRpb24gaGFzIGJlZW4gdXNlZC4gV2h5IGJvdHRl cmluZyB0aGUgQk5HIHdpdGggdGhlDQo+PiAgPmVuY2FwIG9uIHRoZQ0KPj4gID5EU0wgbGluZS4g QW5kIHdoYXQgaWYgbGF0ZXIgc29tZW9uZSB3YW50cyB0byBkbyB0aGUgc2FtZSBvbiBub24tRFNM DQo+PiAgPmFjY2VzcyBsaW5lcz8gQXJlIHdlIGdvaW5nIHRvIGFkZCBlbmNhcCB0eXBlcyBhbmQg dXBkYXRpbmcgdGhlDQo+PiAgPkJORyB3aXRoDQo+PiAgPnRoZXNlIG5ldyBlbmNhcCB0eXBlcyB0 byBjb21wdXRlIHRoZSBjb3JyZWN0IHNoYXBpbmcgcmF0ZT8gSQ0KPj4gID5iZWxpZXZlIGl0DQo+ PiAgPndvdWxkIGJlIGJldHRlciB0byBzcGVjaWZ5IHRoZSBiYW5kd2lkdGggYXQgd2hpY2ggdGhl IEJORyBoYXMgdG8gc2hhcGUuDQo+Pg0KPj4gW1NXXSBTaGFwaW5nIG9uIHRoZSBCTkcgKGJhc2Vk IG9uIGNvdW50aW5nIGJ5dGVzIHRyYW5zbWl0dGVkKSBuZWVkcyB0bw0KPj4ga25vdyB0aGUgImJ5 dGUgYWRqdXN0bWVudCIgKHVuZGVyL292ZXItaGVhZCkgZHVlIHRvIGRpZmZlcmVuY2UgaW4gZW5j YXBzDQo+PiBvbiB0aGUgYWdncmVnYXRpb24gbmV0d29yayBhbmQgYWNjZXNzIGxvb3AuIEkgc3Vw cG9zZSB0aGUgYWNjZXNzLW5vZGUNCj4+IGNvdWxkIGluZGljYXRlIHRoZSBhYnNvbHV0ZSBkaWZm ZXJlbmNlIGluIHRlcm1zIG9mIGJ5dGVzIGJldHdlZW4gdGhlIHR3bw0KPj4gZW5jYXBzdWxhdGlv bnMuLiBob3dldmVyLCB0aGlzIG1pZ2h0IG5vdCBiZSBhY2N1cmF0ZSBhcyBhbiBhZ2dyZWdhdGlv bg0KPj4gc3dpdGNoIHVwc3RyZWFtIG9mIHRoZSBEU0xBTSBjb3VsZCBjaGFuZ2UgdGhlIGVuY2Fw cyAoZS5nLiBpbnNlcnQgYW4NCj4+IG91dGVyIFZMQU4gdGFnKS4gSWRlYWxseSwgdGhlIEJORyBu ZWVkcyB0byB1c2UgdGhlIGRpZmZlcmVuY2UgYmV0d2Vlbg0KPj4gaXQncyBlbmNhcHMgYW5kIHRo ZSBlbmNhcHMgb24gdGhlIGxvY2FsLWxvb3AuIEFsc28sIHRoZSBCTkcgbmVlZHMgdG8NCj4+IGFk anVzdCBmb3IgY2VsbC10YXggaWYgdGhlIGxvY2FsLWxvb3AgaXMgY2VsbCBiYXNlZC4NCj4+DQo+ PiAtU2FuamF5DQo+Pg0KPj4NCj4+ICA+cmVnYXJkcywNCj4+ICA+U3RlZmFhbg0KPj4gID4NCj4+ ICA+DQo+PiAgPj4gICAgICpDaGFwdGVyIDUuNC4yKg0KPj4gID4+ICAgICAtIFR5cG86DQo+PiAg Pj4gICAgIFR5cGUgKEFjY2Vzcy1Mb29wLUNpcmN1aXQtSUQgPSAweDAxKSA6IGRlZmluZWQgaW4g c2VjdGlvbiA1LjQuMQ0KPj4gID4+ICAgICBUeXBlIChBY2Nlc3MtQWdncmVnYXRpb24tQ2lyY3Vp dC1JRC1CaW5hcnkgPSAweDAyKTogZGVmaW5lZCBpbg0KPj4gID4+ICAgICBzZWN0aW9uIDUuNC4x LiAgICAgICAgID4+ICAgICBUeXBlIA0KPj4gKEFjY2Vzcy1BZ2dyZWdhdGlvbi1DaXJjdWl0LUlE LUFTQ0lJID0gMHgwMykgOiBkZWZpbmVkIGluDQo+PiAgPj4gICAgIHNlY3Rpb24gNS40LjEuICAg Pj4gICAgIFRoZXNlIGxpbmVzIHNob3VsZCBiZSB1cGRhdGVkIHRvIA0KPj4gY29tcGx5IHRvIENo YXB0ZXIgNS40LjEuDQo+PiAgPj4NCj4+ICA+PiAgICAgW1tTV11dIFdpbGwgZml4Lg0KPj4gID4+ ICAgICAgID4+ICAgICBUaGFua3MNCj4+ICA+PiAgICAgLVNhbmpheQ0KPj4gID4+DQo+PiAgPj4g ICAgIFRoYW5rcyBhbmQgQmVzdCBSZWdhcmRzLA0KPj4gID4+ICAgICBNaWNoZWwuDQo+PiAgPj4N Cj4+ICA+Pg0KPj4gID4+DQo+PiAgPj4NCj4+ICA+PiAgICAgKiJTYW5qYXkgV2FkaHdhIiA8c3dh ZGh3YUBqdW5pcGVyLm5ldD4qDQo+PiAgPj4NCj4+ICA+PiAgICAgMDUvMDQvMjAwNiAxOToyMg0K Pj4gID4+DQo+PiAgPj4gICAgICAgICAgICAgICAgICAgICAgID4+ICAgICBUbw0KPj4gID4+ICAg ICAgICAgICAgICAgICAgICAgICJCdXNzY2hiYWNoLCBQZXRlciBCIFwoUGV0ZXJcKSINCj4+ICA+ PGJ1c3NjaGJhY2hAbHVjZW50LmNvbT4sICJXb2pjaWVjaA0KPj4gID4+ICAgICBEZWMgXCh3ZGVj XCkiIDx3ZGVjQGNpc2NvLmNvbT4sIDxsMmNwQGlldGYub3JnPg0KPj4gID4+ICAgICBjYw0KPj4g ID4+ICAgICAgICAgICAgICAgICAgICAgICA+PiAgICAgU3ViamVjdA0KPj4gID4+ICAgICAgICAg ICAgICAgICAgICAgIFJFOiBbTDJDUF0gQWR2YW50YWdlcyBvZiBMMkNQICh3YXM6IFJldmlzZWQg DQo+PiBXRyBDaGFydGVyIERyYWZ0KQ0KPj4gID4+DQo+PiAgPj4NCj4+ICA+PiAgICAgICAgICAg ICAgICAgICAgICAgPj4NCj4+ICA+Pg0KPj4gID4+DQo+PiAgPj4NCj4+ICA+Pg0KPj4gID4+ICAg ICBQZXRlcg0KPj4gID4+ICAgICAgUGxlYXNlIHNlZSBpbmxpbmUuLg0KPj4gID4+DQo+PiAgPj4g ICAgICA+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ICA+PiAgICAgID5Gcm9tOiBCdXNz Y2hiYWNoLCBQZXRlciBCIChQZXRlcikNCj4+ICA+W21haWx0bzpidXNzY2hiYWNoQGx1Y2VudC5j b21dDQo+PiAgPj4gICAgICA+U2VudDogV2VkbmVzZGF5LCBBcHJpbCAwNSwgMjAwNiAxMDo1MSBB TQ0KPj4gID4+ICAgICAgPlRvOiAnV29qY2llY2ggRGVjICh3ZGVjKSc7IGwyY3BAaWV0Zi5vcmcN Cj4+ICA+PiAgICAgID5TdWJqZWN0OiBbTDJDUF0gQWR2YW50YWdlcyBvZiBMMkNQICh3YXM6IFJl dmlzZWQgV0cNCj4+ICA+Q2hhcnRlciBEcmFmdCkNCj4+ICA+PiAgICAgID4NCj4+ICA+PiAgICAg ID4NCj4+ICA+PiAgICAgID5IaSBXb2osDQo+PiAgPj4gICAgICA+DQo+PiAgPj4gICAgICA+VG8g YWRkcmVzcyB0aGUgc2Vjb25kIGhhbGYgb2Ygb3VyIGVtYWlsIGV4Y2hhbmdlOg0KPj4gID4+ICAg ICAgPg0KPj4gID4+ICAgICAgPkkgZGlkIG5vdGljZSB0aGUgc2VudGVuY2UgdGhhdCBhZGRyZXNz ZWQgRGF2ZSdzIGNvbmNlcm4uDQo+PiAgPj4gICAgICA+SG93ZXZlciwgbXkgcG9pbnQgd2FzIHRo YXQgdGhlIGNoYXJ0ZXIgY2xhaW1zIHRoYXQgTDJDUCB3aWxsDQo+PiAgPj4gICAgICA+aGF2ZSBh IHNwZWNpZmljIGJlbmVmaXQgKCJhdm9pZGluZyBjb21wbGV4IGNyb3NzLW9yZ2FuaXphdGlvbg0K Pj4gID4+ICAgICAgPmludGVyYWN0aW9ucyIpLCB3aGlsZSBpdCBpcyBmYXIgZnJvbSBjbGVhciB0 aGF0IGluIHRoaXMNCj4+ICA+PiAgICAgID5yZXNwZWN0IEwyQ1AgaXMgYW55IGJldHRlciB0aGFu IG90aGVyIHNvbHV0aW9ucy4NCj4+ICA+Pg0KPj4gID4+ICAgICBbU2FuamF5XSBBbGwgdGhhdCB0 aGUgY2hhcnRlciBpcyBzYXlpbmcgaXMgdGhhdCBMMkMgd29yaw0KPj4gID53aWxsIHVuZGVydGFr ZQ0KPj4gID4+ICAgICB1c2UtY2FzZXMgdGhhdCBhaW0gdG8gc2ltcGxpZnkgc2VydmljZSBtYW5h Z2VtZW50IGJ5DQo+PiAgPmF2b2lkaW5nIGNvbXBsZXgNCj4+ICA+PiAgICAgY3Jvc3Mtb3JnYW5p emF0aW9uIGludGVyYWN0aW9ucy4gSXQgaXMgYSBub2JlbCBnb2FsIHRoYXQNCj4+ICA+TDJDIGlz IHN0cml2aW5nDQo+PiAgPj4gICAgIHRvIGFjaGlldmUuLiBXaGF0IGlzIHdyb25nIHdpdGggdGhh dCA/IFRoaXMgaXMNCj4+ICA+aXJyZXNwZWN0aXZlIG9mIHdldGhlcg0KPj4gID4+ICAgICBvdGhl ciBzb2x1dGlvbnMgY2FuIHByb3ZpZGUgdGhpcyBvciBub3QuDQo+PiAgPj4gICAgIFNvLCBhcyBh biBleGFtcGxlLCBjaGFydGVyIGZvciBhIG5ldyBkeW5hbWljIHJvdXRpbmcNCj4+ICA+cHJvdG9j b2wgbWlnaHQgc2F5DQo+PiAgPj4gICAgIHRoYXQgaXQgd2lsbCBzdHJpdmUgdG8gYWNoaWV2ZSBm YXN0IG5ldHdvcmstd2lkZQ0KPj4gID5jb252ZXJnZW5jZSAod2hpY2ggaXMgYQ0KPj4gID4+ICAg ICBjbGVhciBiZW5lZml0IG92ZXIgc3RhdGljIHJvdXRpbmcpLiBCdXQsIG9idmlvdXNseSBpdCBp cw0KPj4gID5vayBmb3IgbXVsdGlwbGUNCj4+ICA+PiAgICAgZHluYW1pYyByb3V0aW5nIHByb3Rv Y29scyB0byB3b3JrIHRvd2FyZHMgdGhpcyBnb2FsIGFuZCBoYXZlIHRoaXMNCj4+ICA+PiAgICAg ZXhwbGljaXRseSBzdGF0ZWQgaW4gdGhlaXIgY2hhcnRlci4NCj4+ICA+Pg0KPj4gID4+ICAgICAt U2FuamF5DQo+PiAgPj4NCj4+ICA+Pg0KPj4gID4+ICAgICAgPkkgYmVsaWV2ZSB0aGF0IHRoZSBj aGFydGVyIHNob3VsZCBhdm9pZCBzdGF0aW5nIGJlbmVmaXRzIHRoYXQNCj4+ICA+PiAgICAgID5h cmUgZGViYXRhYmxlIGFuZCB0aGVyZWZvcmUgc3VnZ2VzdCB0aGF0IHRoZSB0ZXh0IHRoYXQgSQ0K Pj4gID4+ICAgICAgPnF1b3RlZCBpbiBteSBmaXJzdCBlbWFpbCBiZSBkZWxldGVkIGZyb20gdGhl IGNoYXJ0ZXIuDQo+PiAgPj4gICAgICA+DQo+PiAgPj4gICAgICA+UGV0ZXINCj4+ICA+PiAgICAg ID4NCj4+ICA+PiAgICAgID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiAgPj4gICAg ICA+PiBGcm9tOiBXb2pjaWVjaCBEZWMgKHdkZWMpIFttYWlsdG86d2RlY0BjaXNjby5jb21dDQo+ PiAgPj4gICAgICA+PiBTZW50OiBXZWRuZXNkYXksIEFwcmlsIDA1LCAyMDA2IDc6MzQgQU0NCj4+ ICA+PiAgICAgID4+IFRvOiBCdXNzY2hiYWNoLCBQZXRlciBCIChQZXRlcik7IGwyY3BAaWV0Zi5v cmcNCj4+ICA+PiAgICAgID4+IFN1YmplY3Q6IFJFOiBbTDJDUF0gUmU6IFJldmlzZWQgV0cgQ2hh cnRlciBEcmFmdA0KPj4gID4+ICAgICAgPj4NCj4+ICA+PiAgICAgID4+DQo+PiAgPj4gICAgICA+ PiBIaSBQZXRlciwNCj4+ICA+PiAgICAgID4+DQo+PiAgPj4gICAgICA+PiBUbyBhZGRyZXNzIDEp IHdlIGhhdmUgcHV0IGluIHRoZSBmb2xsb3dpbmcgc3RhdGVtZW50DQo+PiAgPmluIHRoZSBjaGFy dGVyDQo+PiAgPj4gICAgICA+PiB3aGljaCB5b3UgbWF5IGhhdmUgbm90IG5vdGljZWQuDQo+PiAg Pj4gICAgICA+Pg0KPj4gID4+ICAgICAgPj4gIlRoZSBwcm90b2NvbCBkZXNpZ24gd2lsbCBub3Qg cHJlY2x1ZGUgb3RoZXIgdXNlcyBvZiBMMkNQLiINCj4+ICA+PiAgICAgID4+DQo+PiAgPj4gICAg ICA+PiBXUlQgMikgd2UgZG8gbm90IGxheSBhbnkgY2xhaW1zIHRvIGhvdyBkaWZmZXJlbnQNCj4+ ICA+b3BlcmF0b3JzIHN0cnVjdHVyZQ0KPj4gID4+ICAgICAgPj4gdGhlaXIgZGF0YSBiYXNlcywg YW5kIHNvbWUgYXJlIHByb2JhYmx5IGJldHRlciBhdCBkb2luZyBpdA0KPj4gID4+ICAgICAgPj4g dGhhbiBvdGhlcnMuDQo+PiAgPj4gICAgICA+PiBIb3dldmVyIGl0IGRvZXMgc2VlbSB0byBiZSBh IGZhaXJseSBjb21tb24gcHJvYmxlbSB0aGF0IHRoZQ0KPj4gID4+ICAgICAgPj4gaW5mbyByZWxh dGVkDQo+PiAgPj4gICAgICA+PiB0byBhIHNpbmdsZSBzdWJzY3JpYmVyJ3MgbmV0d29yayBzZXJ2 aWNlIG5lZWRzIHRvIGJlIGZhcm1lZA0KPj4gID4+ICAgICAgPj4gb3V0IGFuZCBmZWQNCj4+ICA+ PiAgICAgID4+IGludG8gbnVtZXJvdXMgY3VzdG9tIGJ1aWx0IG1hbmFnZXIgc3lzdGVtcyBiZXNp ZGVzIGFsc28gdGhlDQo+PiAgPj4gICAgICA+UmFkaXVzIERCLg0KPj4gID4+ICAgICAgPj4gVGhl IGlkZWEgaXMgdG8gYWxsb3cgYSBtZWNoYW5pc20sIHRocm91Z2ggdGhlIHVzZSBvZiBMMkNQLA0K Pj4gID4+ICAgICAgPnRvIGhhdmUgdGhlDQo+PiAgPj4gICAgICA+PiBBY2Nlc3Mgbm9kZSBiZSBw cm92aWRlZCB3aXRoIHN1Y2ggaW5mb3JtYXRpb24gYXMgYW5kIHdoZW4NCj4+ICA+PiAgICAgID4+ IG5lZWRlZCBieSB0aGUNCj4+ICA+PiAgICAgID4+IE5BUyB3aGljaCBpbiB0dXJuIGFjY2Vzc2Vz IGEgY29tbW9uIHJlcG9zaXRvcnkgbGlrZQ0KPj4gID5hIFJhZGl1cyBEQi4NCj4+ICA+PiAgICAg ID4+IERhdmUncyBzdGF0ZW1lbnQgd2FzLCBJIGJlbGlldmUsIGluIHJlbGF0aW9uIHRvIGRpZmZl cmVudA0KPj4gID4+ICAgICAgPj4gc3ViamVjdDsgdGhhdA0KPj4gID4+ICAgICAgPj4gb2YgYSB3 aG9sZXNhbGUtcmV0YWlsIG9wZXJhdGlvbiwgd2hlcmUgaW5kZWVkIHRoZQ0KPj4gID4+ICAgICAg PnJlbGF0aW9uc2hpcCBpcyBtb3JlDQo+PiAgPj4gICAgICA+PiBjb21wbGV4LiBIb3dldmVyIHdl IGRvIHBsYW4gb24gYWRkcmVzc2luZyB0aGlzIGFzDQo+PiAgPmV2aWRlbmNlZCBieSB0aGUNCj4+ ICA+PiAgICAgID4+IHN0YXRlbWVudCBpbiB0aGUgY2hhcnRlcjoNCj4+ICA+PiAgICAgID4+ICJM MkNQIHdpbGwgYWRkcmVzcyBzZWN1cml0eSBhc3BlY3RzIG9mIHRoZSBjb250cm9sIHByb3RvY29s LA0KPj4gID4+ICAgICAgPmluY2x1ZGluZw0KPj4gID4+ICAgICAgPj4gdGhlIHRydXN0IG1vZGVs IGJldHdlZW4gTkFTIG5vZGVzIGFuZCBhY2Nlc3Mgbm9kZXMuIg0KPj4gID4+ICAgICAgPj4NCj4+ ICA+PiAgICAgID4+IFJlZ2FyZHMsDQo+PiAgPj4gICAgICA+PiBXb2ouDQo+PiAgPj4gICAgICA+ Pg0KPj4gID4+ICAgICAgPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ICA+PiAgICAg ID4+IEZyb206IEJ1c3NjaGJhY2gsIFBldGVyIEIgKFBldGVyKQ0KPj4gID5bbWFpbHRvOmJ1c3Nj aGJhY2hAbHVjZW50LmNvbV0NCj4+ICA+PiAgICAgID4+IFNlbnQ6IDA0IEFwcmlsIDIwMDYgMjE6 MjMNCj4+ICA+PiAgICAgID4+IFRvOiAnbDJjcEBpZXRmLm9yZycNCj4+ICA+PiAgICAgID4+IFN1 YmplY3Q6IFtMMkNQXSBSZTogUmV2aXNlZCBXRyBDaGFydGVyIERyYWZ0DQo+PiAgPj4gICAgICA+ Pg0KPj4gID4+ICAgICAgPj4gSSBoYXZlIHR3byBjb21tZW50cyBvbiB0aGUgcmV2aXNlZCBjaGFy dGVyLg0KPj4gID4+ICAgICAgPj4NCj4+ICA+PiAgICAgID4+IDEpICAgICAgICAgICAgICAgICBB dCB0aGUgZW5kIG9mIHRoZSBCT0YsIE1hcmsNCj4+ICA+VG93bnNsZXkgbGltaXRlZA0KPj4gID4+ ICAgICB0aGUgc2NvcGUgb2YgdGhlDQo+PiAgPj4gICAgICA+PiB3b3JraW5nIGdyb3VwLiBVbmZv cnR1bmF0ZWx5LCB0aGlzIGlzIG5vdCBjYXB0dXJlZCB2ZXJ5DQo+PiAgPj4gICAgICA+Y2xlYXJs eSBpbiB0aGUNCj4+ICA+PiAgICAgID4+IG1lZXRpbmcgbWludXRlcy4gVGhlIGNyaXRpY2FsIHNl bnRlbmNlIGluIHRoZQ0KPj4gID5tZWV0aW5nIG1pbnV0ZXMgaXMNCj4+ICA+PiAgICAgIkRTTA0K Pj4gID4+ICAgICAgPj4gYnV0IGdvb2QgZW5naW5lZXJzIC4uLiIuIEkuZS4gdGhlIGZvY3VzIG9m IHRoZSBXRyBpcw0KPj4gID50byBzb2x2ZSBhDQo+PiAgPj4gICAgICA+PiBwYXJ0aWN1bGFyIGlz c3VlIGluIERTTCBhY2Nlc3MgbmV0d29ya3MsIGJ1dCBhcyBnb29kDQo+PiAgPj4gICAgICA+PiBl bmdpbmVlcnMgd2Ugc2hvdWxkDQo+PiAgPj4gICAgICA+PiBub3QgcHJlY2x1ZGUgdGhlIHVzZSBv ZiB0aGUgcHJvdG9jb2wgZm9yIG90aGVyIGFwcGxpY2F0aW9ucy4NCj4+ICA+PiAgICAgID4+DQo+ PiAgPj4gICAgICA+PiBJIGRvbid0IHNlZSB0aGUgbGltaXRlZCBzY29wZSByZWZsZWN0ZWQgaW4g dGhlIG5ldyBjaGFydGVyLg0KPj4gID4+ICAgICAgPj4NCj4+ICA+PiAgICAgID4+IDIpICAgICAg ICAgICAgICAgICBVbmRlciAiTGluZSBDb25maWd1cmF0aW9uIi4gdGhlDQo+PiAgPmNoYXJ0ZXIg c2F5czoNCj4+ICA+PiAgICAgID4+DQo+PiAgPj4gICAgICA+PiA+IEwyQ1AgaXMgaW50ZW5kZWQg dG8gc2ltcGxpZnkgdGhlIE9TUw0KPj4gID5pbmZyYXN0cnVjdHVyZSBmb3Igc2VydmljZQ0KPj4g ID4+ICAgICAgPj4gPiBtYW5hZ2VtZW50LCBhbGxvd2luZyBzdWJzY3JpYmVyLXJlbGF0ZWQgc2Vy dmljZSBkYXRhIHRvIGJlDQo+PiAgPj4gICAgICA+PiBtYWludGFpbmVkDQo+PiAgPj4gICAgICA+ PiA+IGluIGZld2VyIHJlcG9zaXRvcmllcyAoZS5nLiBSQURJVVMgc2VydmVyIGJhY2stZW5kDQo+ PiAgPmRhdGFiYXNlKQ0KPj4gID4+ICAgICB3aGlsZQ0KPj4gID4+ICAgICAgPj4gPiBhdm9pZGlu ZyBjb21wbGV4IGNyb3NzLW9yZ2FuaXphdGlvbiBpbnRlcmFjdGlvbnMuDQo+PiAgPj4gICAgICA+ Pg0KPj4gID4+ICAgICAgPj4gSSBkb24ndCB1bmRlcnN0YW5kIGhvdyBMMkNQIGxlYWRzIHRvIGZl d2VyIFJhZGl1cyBzZXJ2ZXINCj4+ICA+PiAgICAgID5iYWNrIGVuZCBkYXRhDQo+PiAgPj4gICAg ICA+PiBiYXNlcy4gSSBhbHNvIGRvbid0IHVuZGVyc3RhbmQgaG93IEwyQ1AgYXZvaWRzDQo+PiAg PmNyb3NzLW9yZ2FuaXphdGlvbmFsDQo+PiAgPj4gICAgICA+PiBpbnRlcmFjdGlvbnMuIFRoZXJl IHNlZW1zIHRvIGJlIGFuIGFzc3VtcHRpb24gdGhhdCBpdCBpcyBvaw0KPj4gID4+ICAgICAgPj4g Zm9yIEwyQ1AgdG8NCj4+ICA+PiAgICAgID4+IGNyb3NzIG9yZ2FuaXphdGlvbmFsIGJvdW5kYXJp ZXMgYnV0IG5vdCBmb3Igb3RoZXINCj4+ICA+cHJvdG9jb2xzLiBJIGRvbid0DQo+PiAgPj4gICAg ICA+PiB0aGluayB0aGF0IGlzIGNvcnJlY3QuIEF0IHRoZSBCT0YsIERhdmUgQWxsYW4gcG9pbnRl ZCBvdXQgIA0KPj4gID4+ICAgICAgPj4gdGhhdCB0aGlzIGlzDQo+PiAgPj4gICAgICA+PiBvbmUg b2YgdGhlIG1vcmUgZGlmZmljdWx0IHByb2JsZW1zIHRvIHNvbHZlLiBUaGVyZWZvcmUsIEkNCj4+ ICA+PiAgICAgID5iZWxpZXZlIHRoYXQNCj4+ICA+PiAgICAgID4+IHRoaXMgdGV4dCBzaG91bGQg YmUgcmVtb3ZlZCBmcm9tIHRoZSBjaGFydGVyLg0KPj4gID4+ICAgICAgPj4NCj4+ICA+PiAgICAg ID4+IFBldGVyDQo+IA0KPiANCg== --===============1375103526== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ L2cp mailing list L2cp@ietf.org https://www1.ietf.org/mailman/listinfo/l2cp --===============1375103526==-- From l2cp-bounces@ietf.org Tue May 30 04:11:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkzJh-0000DH-3x; Tue, 30 May 2006 04:11:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkzJg-0000DC-II for l2cp@ietf.org; Tue, 30 May 2006 04:11:04 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkzJd-0006Yk-RS for l2cp@ietf.org; Tue, 30 May 2006 04:11:04 -0400 Received: from unknown (HELO emailfeemea2.jnpr.net) ([172.26.192.142]) by kremlin.juniper.net with ESMTP; 30 May 2006 01:11:01 -0700 X-IronPort-AV: i="4.05,188,1146466800"; d="scan'208"; a="550267563:sNHT59696464" Received: from emailemea5.jnpr.net ([172.26.192.134]) by emailfeemea2.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 May 2006 09:10:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation Date: Tue, 30 May 2006 09:10:59 +0100 Message-ID: In-Reply-To: <447AE499.3050403@alcatel.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [L2CP] RE: Wadhwa new draft 01- Encapsulation Thread-Index: AcaDGO+8YOlRMk1hSB+T1+1P4JFNqQAp3nJA From: "Derek Harkness" To: X-OriginalArrivalTime: 30 May 2006 08:10:59.0925 (UTC) FILETIME=[95F1D050:01C683C0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 544c2133b952fa264803d857bb70855b Cc: l2cp@ietf.org X-BeenThere: l2cp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Layer 2 Control Protocol Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: l2cp-bounces@ietf.org I understand that if this is a fixed overhead it should be subtracted from the BW before it is passed in ANCP. However I understood that there are packet length dependent overheads on the line encoding which cannot be handled in this way.=20 Cheers, Derek. =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 -----Original Message----- From: stefaan.de_cnodder@alcatel.be [mailto:stefaan.de_cnodder@alcatel.be]=20 Sent: 29 May 2006 14:10 To: Derek Harkness Cc: l2cp@ietf.org Subject: Re: [L2CP] RE: Wadhwa new draft 01- Encapsulation Hi Derek, see below Derek Harkness wrote: > =20 > We have seen this from deployments using VDSL2 DSLAMs. My understanding=20 > is that the overhead is due to the local loop framing which includes=20 > FEC, trellis encoding and other factors. Possibly this can be derived=20 > from the DSL type which we already have in the protocol - I am not=20 > familiar enough with the details of all DSL encodings to be able to=20 > judge that, maybe the access node experts could shed some light here ? > =20 These physical layer overhead cannot be derived from the DSL type=20 because trellis encoding for instance can be switched off or on.=20 However, this overhead of the physical layer is already substracted from the physical bit rate when computing the actual bit rate so I guess=20 there are no issue. regards, Stefaan > Cheers, > =20 > Derek. > =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 > 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:* Michel.Platnic@ecitele.com [mailto:Michel.Platnic@ecitele.com] > *Sent:* 24 May 2006 11:46 > *To:* Sanjay Wadhwa > *Cc:* l2cp@ietf.org > *Subject:* RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation >=20 >=20 > Hi Sanjay and all, > I support Sanjay's proposal to have this encapsulation transported by=20 > ANCP, even if we may argue that > we already have 2 protocols that may transport this information (DHCP=20 > and PPPoE). > About having a different TLV to transport the Encapsulation, it only=20 > partially solves the problem of potentially mixing > layer 1 and layer 2 information. Actually the DSL forum (TR-101) uses=20 > same principle described in your document to transport this > information, it is probably wise to follow the same mechanism.. > Unless other people share this concern, I'll go with your proposal. > Best Regards, > Michel. >=20 >=20 >=20 > *"Sanjay Wadhwa" * >=20 > 24/05/2006 00:01 >=20 > =09 > To > > cc > l2cp@ietf.org > Subject > RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation + Remode Id comments >=20 >=20 > =09 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > >-----Original Message----- > >From: stefaan.de_cnodder@alcatel.be > >[mailto:stefaan.de_cnodder@alcatel.be] > >Sent: Tuesday, May 23, 2006 1:07 PM > >To: Sanjay Wadhwa > >Cc: l2cp@ietf.org > >Subject: Re: [L2CP] RE: Wadhwa new draft 01- Encapsulation + Remode Id > >comments > > > > > > > >Hi Sanjay, > > > >> > >> - Why was the access loop encapsulation object included within a > >> message where all parameters transmitted are layer 1 oriented? > >> There might be several encapsulations available per > >physical link, a > >> new message could maybe better serve the purpose of > >> transmitting the encapsulation parameters. > >> [[SW]] I have sympathy for your arguement as I had a similar > >> concern, which is why L2 encaps has been specified as a > >seprate and > >> optional TLV (although same message). > >> It is to an extent useful for the BNG to learn l2 encaps on the > >> local-loop as it can in some cases allow for more > >accurate shaping > >> of subscriber traffic. > >> > > > >Why not specifying the bandwidth at L2? Then the BNG just takes this > >bandwidth for shaping and it does not have to take care of what > >encapsulation has been used. Why bottering the BNG with the > >encap on the > >DSL line. And what if later someone wants to do the same on non-DSL > >access lines? Are we going to add encap types and updating the > >BNG with > >these new encap types to compute the correct shaping rate? I > >believe it > >would be better to specify the bandwidth at which the BNG has to shape. >=20 > [SW] Shaping on the BNG (based on counting bytes transmitted) needs to > know the "byte adjustment" (under/over-head) due to difference in encaps > on the aggregation network and access loop. I suppose the access-node > could indicate the absolute difference in terms of bytes between the two > encapsulations.. however, this might not be accurate as an aggregation > switch upstream of the DSLAM could change the encaps (e.g. insert an > outer VLAN tag). Ideally, the BNG needs to use the difference between > it's encaps and the encaps on the local-loop. Also, the BNG needs to > adjust for cell-tax if the local-loop is cell based. >=20 > -Sanjay >=20 >=20 > >regards, > >Stefaan > > > > > >> *Chapter 5.4.2* > >> - Typo: > >> Type (Access-Loop-Circuit-ID =3D 0x01) : defined in section 5.4.1 > >> Type (Access-Aggregation-Circuit-ID-Binary =3D 0x02): defined = in > >> section 5.4.1. =20 > >> Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03) : defined = in > >> section 5.4.1. =20 > >> These lines should be updated to comply to Chapter 5.4.1. > >> > >> [[SW]] Will fix. > >> =20 > >> Thanks > >> -Sanjay > >> > >> Thanks and Best Regards, > >> Michel. > >> > >> > >> > >> > >> *"Sanjay Wadhwa" * > >> > >> 05/04/2006 19:22 > >> > >> =20 > >> To > >> "Busschbach, Peter B \(Peter\)" > >, "Wojciech > >> Dec \(wdec\)" , > >> cc > >> =20 > >> Subject > >> RE: [L2CP] Advantages of L2CP (was: Revised WG=20 > Charter Draft) > >> > >> > >> =20 > >> > >> > >> > >> > >> > >> Peter > >> Please see inline.. > >> > >> >-----Original Message----- > >> >From: Busschbach, Peter B (Peter) > >[mailto:busschbach@lucent.com] > >> >Sent: Wednesday, April 05, 2006 10:51 AM > >> >To: 'Wojciech Dec (wdec)'; l2cp@ietf.org > >> >Subject: [L2CP] Advantages of L2CP (was: Revised WG > >Charter Draft) > >> > > >> > > >> >Hi Woj, > >> > > >> >To address the second half of our email exchange: > >> > > >> >I did notice the sentence that addressed Dave's concern. > >> >However, my point was that the charter claims that L2CP will > >> >have a specific benefit ("avoiding complex cross-organization > >> >interactions"), while it is far from clear that in this > >> >respect L2CP is any better than other solutions. > >> > >> [Sanjay] All that the charter is saying is that L2C work > >will undertake > >> use-cases that aim to simplify service management by > >avoiding complex > >> cross-organization interactions. It is a nobel goal that > >L2C is striving > >> to achieve.. What is wrong with that ? This is > >irrespective of wether > >> other solutions can provide this or not. > >> So, as an example, charter for a new dynamic routing > >protocol might say > >> that it will strive to achieve fast network-wide > >convergence (which is a > >> clear benefit over static routing). But, obviously it is > >ok for multiple > >> dynamic routing protocols to work towards this goal and have this > >> explicitly stated in their charter. > >> > >> -Sanjay > >> > >> > >> >I believe that the charter should avoid stating benefits that > >> >are debatable and therefore suggest that the text that I > >> >quoted in my first email be deleted from the charter. > >> > > >> >Peter > >> > > >> >> -----Original Message----- > >> >> From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] > >> >> Sent: Wednesday, April 05, 2006 7:34 AM > >> >> To: Busschbach, Peter B (Peter); l2cp@ietf.org > >> >> Subject: RE: [L2CP] Re: Revised WG Charter Draft > >> >> > >> >> > >> >> Hi Peter, > >> >> > >> >> To address 1) we have put in the following statement > >in the charter > >> >> which you may have not noticed. > >> >> > >> >> "The protocol design will not preclude other uses of L2CP." > >> >> > >> >> WRT 2) we do not lay any claims to how different > >operators structure > >> >> their data bases, and some are probably better at doing it > >> >> than others. > >> >> However it does seem to be a fairly common problem that the > >> >> info related > >> >> to a single subscriber's network service needs to be farmed > >> >> out and fed > >> >> into numerous custom built manager systems besides also the > >> >Radius DB. > >> >> The idea is to allow a mechanism, through the use of L2CP, > >> >to have the > >> >> Access node be provided with such information as and when > >> >> needed by the > >> >> NAS which in turn accesses a common repository like > >a Radius DB. > >> >> Dave's statement was, I believe, in relation to different > >> >> subject; that > >> >> of a wholesale-retail operation, where indeed the > >> >relationship is more > >> >> complex. However we do plan on addressing this as > >evidenced by the > >> >> statement in the charter: > >> >> "L2CP will address security aspects of the control protocol, > >> >including > >> >> the trust model between NAS nodes and access nodes." > >> >> > >> >> Regards, > >> >> Woj. > >> >> > >> >> -----Original Message----- > >> >> From: Busschbach, Peter B (Peter) > >[mailto:busschbach@lucent.com] > >> >> Sent: 04 April 2006 21:23 > >> >> To: 'l2cp@ietf.org' > >> >> Subject: [L2CP] Re: Revised WG Charter Draft > >> >> > >> >> I have two comments on the revised charter. > >> >> > >> >> 1) At the end of the BOF, Mark > >Townsley limited > >> the scope of the > >> >> working group. Unfortunately, this is not captured very > >> >clearly in the > >> >> meeting minutes. The critical sentence in the > >meeting minutes is > >> "DSL > >> >> but good engineers ...". I.e. the focus of the WG is > >to solve a > >> >> particular issue in DSL access networks, but as good > >> >> engineers we should > >> >> not preclude the use of the protocol for other applications. > >> >> > >> >> I don't see the limited scope reflected in the new charter. > >> >> > >> >> 2) Under "Line Configuration". the > >charter says: > >> >> > >> >> > L2CP is intended to simplify the OSS > >infrastructure for service > >> >> > management, allowing subscriber-related service data to be > >> >> maintained > >> >> > in fewer repositories (e.g. RADIUS server back-end > >database) > >> while > >> >> > avoiding complex cross-organization interactions. > >> >> > >> >> I don't understand how L2CP leads to fewer Radius server > >> >back end data > >> >> bases. I also don't understand how L2CP avoids > >cross-organizational > >> >> interactions. There seems to be an assumption that it is ok > >> >> for L2CP to > >> >> cross organizational boundaries but not for other > >protocols. I don't > >> >> think that is correct. At the BOF, Dave Allan pointed out > >> >> that this is > >> >> one of the more difficult problems to solve. Therefore, I > >> >believe that > >> >> this text should be removed from the charter. > >> >> > >> >> Peter > >> >> > >> >> > >> >> > >> >> _______________________________________________ > >> >> L2cp mailing list > >> >> L2cp@ietf.org > >> >> https://www1.ietf.org/mailman/listinfo/l2cp > >> >> > >> > > >> >_______________________________________________ > >> >L2cp mailing list > >> >L2cp@ietf.org > >> >https://www1.ietf.org/mailman/listinfo/l2cp > >> > > >> > >> _______________________________________________ > >> L2cp mailing list > >> L2cp@ietf.org > >> https://www1.ietf.org/mailman/listinfo/l2cp > >> > >> > >> > >--------------------------------------------------------------- > >--------- > >> > >> _______________________________________________ > >> L2cp mailing list > >> L2cp@ietf.org > >> https://www1.ietf.org/mailman/listinfo/l2cp > > >=20 > _______________________________________________ > L2cp mailing list > L2cp@ietf.org > https://www1.ietf.org/mailman/listinfo/l2cp >=20 >=20 > ------------------------------------------------------------------------ >=20 > _______________________________________________ > L2cp mailing list > L2cp@ietf.org > https://www1.ietf.org/mailman/listinfo/l2cp _______________________________________________ L2cp mailing list L2cp@ietf.org https://www1.ietf.org/mailman/listinfo/l2cp From l2cp-bounces@ietf.org Tue May 30 06:49:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl1mr-0002Sb-Jt; Tue, 30 May 2006 06:49:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl1mq-0002SR-Ds for l2cp@ietf.org; Tue, 30 May 2006 06:49:20 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl1mn-0005bt-Je for l2cp@ietf.org; Tue, 30 May 2006 06:49:20 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Tue, 30 May 2006 12:49:10 +0200 Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 30 May 2006 12:49:09 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED287CEDD@S4DE8PSAAFQ.mitte.t-com.de> From: "Haag, T" To: dharkness@juniper.net Subject: AW: [L2CP] RE: Wadhwa new draft 01- Encapsulation Date: Tue, 30 May 2006 12:49:03 +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: 8f3b9db08b8c0fe2301a77f547096e31 Cc: l2cp@ietf.org X-BeenThere: l2cp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Layer 2 Control Protocol Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: l2cp-bounces@ietf.org I share Derek's view. I have some concerns that signalling of the encapsulation will solve = the problem at all because a real impact in shaping and corresponding = overhead is the IP packet length which is not fix. Also to have different encapsulation types (like PPPoE and IPoE) in one = circuit (VLAN or PVC) will not be solved. Regards Thomas -----Urspr=FCngliche Nachricht----- Von: Derek Harkness [mailto:dharkness@juniper.net]=20 Gesendet: Dienstag, 30. Mai 2006 10:11 An: stefaan.de_cnodder@alcatel.be Cc: l2cp@ietf.org Betreff: RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation I understand that if this is a fixed overhead it should be subtracted from the BW before it is passed in ANCP. However I understood that = there are packet length dependent overheads on the line encoding which cannot be handled in this way.=20 Cheers, Derek. =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 -----Original Message----- From: stefaan.de_cnodder@alcatel.be [mailto:stefaan.de_cnodder@alcatel.be]=20 Sent: 29 May 2006 14:10 To: Derek Harkness Cc: l2cp@ietf.org Subject: Re: [L2CP] RE: Wadhwa new draft 01- Encapsulation Hi Derek, see below Derek Harkness wrote: > =20 > We have seen this from deployments using VDSL2 DSLAMs. My understanding=20 > is that the overhead is due to the local loop framing which includes=20 > FEC, trellis encoding and other factors. Possibly this can be derived = > from the DSL type which we already have in the protocol - I am not=20 > familiar enough with the details of all DSL encodings to be able to=20 > judge that, maybe the access node experts could shed some light here = ? > =20 These physical layer overhead cannot be derived from the DSL type=20 because trellis encoding for instance can be switched off or on.=20 However, this overhead of the physical layer is already substracted = from the physical bit rate when computing the actual bit rate so I guess=20 there are no issue. regards, Stefaan > Cheers, > =20 > Derek. > =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 > 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:* Michel.Platnic@ecitele.com = [mailto:Michel.Platnic@ecitele.com] > *Sent:* 24 May 2006 11:46 > *To:* Sanjay Wadhwa > *Cc:* l2cp@ietf.org > *Subject:* RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation >=20 >=20 > Hi Sanjay and all, > I support Sanjay's proposal to have this encapsulation transported by = > ANCP, even if we may argue that > we already have 2 protocols that may transport this information (DHCP = > and PPPoE). > About having a different TLV to transport the Encapsulation, it only=20 > partially solves the problem of potentially mixing > layer 1 and layer 2 information. Actually the DSL forum (TR-101) uses = > same principle described in your document to transport this > information, it is probably wise to follow the same mechanism.. > Unless other people share this concern, I'll go with your proposal. > Best Regards, > Michel. >=20 >=20 >=20 > *"Sanjay Wadhwa" * >=20 > 24/05/2006 00:01 >=20 > =09 > To > > cc > l2cp@ietf.org > Subject > RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation + Remode Id comments >=20 >=20 > =09 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > >-----Original Message----- > >From: stefaan.de_cnodder@alcatel.be > >[mailto:stefaan.de_cnodder@alcatel.be] > >Sent: Tuesday, May 23, 2006 1:07 PM > >To: Sanjay Wadhwa > >Cc: l2cp@ietf.org > >Subject: Re: [L2CP] RE: Wadhwa new draft 01- Encapsulation + Remode Id > >comments > > > > > > > >Hi Sanjay, > > > >> > >> - Why was the access loop encapsulation object included = within a > >> message where all parameters transmitted are layer 1 = oriented? > >> There might be several encapsulations available per > >physical link, a > >> new message could maybe better serve the purpose of > >> transmitting the encapsulation parameters. > >> [[SW]] I have sympathy for your arguement as I had a similar > >> concern, which is why L2 encaps has been specified as a > >seprate and > >> optional TLV (although same message). > >> It is to an extent useful for the BNG to learn l2 encaps on the > >> local-loop as it can in some cases allow for more > >accurate shaping > >> of subscriber traffic. > >> > > > >Why not specifying the bandwidth at L2? Then the BNG just takes = this > >bandwidth for shaping and it does not have to take care of what > >encapsulation has been used. Why bottering the BNG with the > >encap on the > >DSL line. And what if later someone wants to do the same on non-DSL > >access lines? Are we going to add encap types and updating the > >BNG with > >these new encap types to compute the correct shaping rate? I > >believe it > >would be better to specify the bandwidth at which the BNG has to shape. >=20 > [SW] Shaping on the BNG (based on counting bytes transmitted) needs = to > know the "byte adjustment" (under/over-head) due to difference in encaps > on the aggregation network and access loop. I suppose the access-node > could indicate the absolute difference in terms of bytes between the two > encapsulations.. however, this might not be accurate as an = aggregation > switch upstream of the DSLAM could change the encaps (e.g. insert an > outer VLAN tag). Ideally, the BNG needs to use the difference between > it's encaps and the encaps on the local-loop. Also, the BNG needs to > adjust for cell-tax if the local-loop is cell based. >=20 > -Sanjay >=20 >=20 > >regards, > >Stefaan > > > > > >> *Chapter 5.4.2* > >> - Typo: > >> Type (Access-Loop-Circuit-ID =3D 0x01) : defined in section 5.4.1 > >> Type (Access-Aggregation-Circuit-ID-Binary =3D 0x02): defined = in > >> section 5.4.1. =20 > >> Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03) : defined = in > >> section 5.4.1. =20 > >> These lines should be updated to comply to Chapter 5.4.1. > >> > >> [[SW]] Will fix. > >> =20 > >> Thanks > >> -Sanjay > >> > >> Thanks and Best Regards, > >> Michel. > >> > >> > >> > >> > >> *"Sanjay Wadhwa" * > >> > >> 05/04/2006 19:22 > >> > >> =20 > >> To > >> "Busschbach, Peter B \(Peter\)" > >, "Wojciech > >> Dec \(wdec\)" , > >> cc > >> =20 > >> Subject > >> RE: [L2CP] Advantages of L2CP (was: Revised WG=20 > Charter Draft) > >> > >> > >> =20 > >> > >> > >> > >> > >> > >> Peter > >> Please see inline.. > >> > >> >-----Original Message----- > >> >From: Busschbach, Peter B (Peter) > >[mailto:busschbach@lucent.com] > >> >Sent: Wednesday, April 05, 2006 10:51 AM > >> >To: 'Wojciech Dec (wdec)'; l2cp@ietf.org > >> >Subject: [L2CP] Advantages of L2CP (was: Revised WG > >Charter Draft) > >> > > >> > > >> >Hi Woj, > >> > > >> >To address the second half of our email exchange: > >> > > >> >I did notice the sentence that addressed Dave's concern. > >> >However, my point was that the charter claims that L2CP = will > >> >have a specific benefit ("avoiding complex cross-organization > >> >interactions"), while it is far from clear that in this > >> >respect L2CP is any better than other solutions. > >> > >> [Sanjay] All that the charter is saying is that L2C work > >will undertake > >> use-cases that aim to simplify service management by > >avoiding complex > >> cross-organization interactions. It is a nobel goal that > >L2C is striving > >> to achieve.. What is wrong with that ? This is > >irrespective of wether > >> other solutions can provide this or not. > >> So, as an example, charter for a new dynamic routing > >protocol might say > >> that it will strive to achieve fast network-wide > >convergence (which is a > >> clear benefit over static routing). But, obviously it is > >ok for multiple > >> dynamic routing protocols to work towards this goal and have this > >> explicitly stated in their charter. > >> > >> -Sanjay > >> > >> > >> >I believe that the charter should avoid stating benefits that > >> >are debatable and therefore suggest that the text that I > >> >quoted in my first email be deleted from the charter. > >> > > >> >Peter > >> > > >> >> -----Original Message----- > >> >> From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] > >> >> Sent: Wednesday, April 05, 2006 7:34 AM > >> >> To: Busschbach, Peter B (Peter); l2cp@ietf.org > >> >> Subject: RE: [L2CP] Re: Revised WG Charter Draft > >> >> > >> >> > >> >> Hi Peter, > >> >> > >> >> To address 1) we have put in the following statement > >in the charter > >> >> which you may have not noticed. > >> >> > >> >> "The protocol design will not preclude other uses of L2CP." > >> >> > >> >> WRT 2) we do not lay any claims to how different > >operators structure > >> >> their data bases, and some are probably better at doing = it > >> >> than others. > >> >> However it does seem to be a fairly common problem that the > >> >> info related > >> >> to a single subscriber's network service needs to be farmed > >> >> out and fed > >> >> into numerous custom built manager systems besides also the > >> >Radius DB. > >> >> The idea is to allow a mechanism, through the use of = L2CP, > >> >to have the > >> >> Access node be provided with such information as and when > >> >> needed by the > >> >> NAS which in turn accesses a common repository like > >a Radius DB. > >> >> Dave's statement was, I believe, in relation to different > >> >> subject; that > >> >> of a wholesale-retail operation, where indeed the > >> >relationship is more > >> >> complex. However we do plan on addressing this as > >evidenced by the > >> >> statement in the charter: > >> >> "L2CP will address security aspects of the control protocol, > >> >including > >> >> the trust model between NAS nodes and access nodes." > >> >> > >> >> Regards, > >> >> Woj. > >> >> > >> >> -----Original Message----- > >> >> From: Busschbach, Peter B (Peter) > >[mailto:busschbach@lucent.com] > >> >> Sent: 04 April 2006 21:23 > >> >> To: 'l2cp@ietf.org' > >> >> Subject: [L2CP] Re: Revised WG Charter Draft > >> >> > >> >> I have two comments on the revised charter. > >> >> > >> >> 1) At the end of the BOF, Mark > >Townsley limited > >> the scope of the > >> >> working group. Unfortunately, this is not captured very > >> >clearly in the > >> >> meeting minutes. The critical sentence in the > >meeting minutes is > >> "DSL > >> >> but good engineers ...". I.e. the focus of the WG is > >to solve a > >> >> particular issue in DSL access networks, but as good > >> >> engineers we should > >> >> not preclude the use of the protocol for other applications. > >> >> > >> >> I don't see the limited scope reflected in the new charter. > >> >> > >> >> 2) Under "Line Configuration". the > >charter says: > >> >> > >> >> > L2CP is intended to simplify the OSS > >infrastructure for service > >> >> > management, allowing subscriber-related service data to be > >> >> maintained > >> >> > in fewer repositories (e.g. RADIUS server back-end > >database) > >> while > >> >> > avoiding complex cross-organization interactions. > >> >> > >> >> I don't understand how L2CP leads to fewer Radius server > >> >back end data > >> >> bases. I also don't understand how L2CP avoids > >cross-organizational > >> >> interactions. There seems to be an assumption that it is ok > >> >> for L2CP to > >> >> cross organizational boundaries but not for other > >protocols. I don't > >> >> think that is correct. At the BOF, Dave Allan pointed out > >> >> that this is > >> >> one of the more difficult problems to solve. Therefore, I > >> >believe that > >> >> this text should be removed from the charter. > >> >> > >> >> Peter > >> >> > >> >> > >> >> > >> >> _______________________________________________ > >> >> L2cp mailing list > >> >> L2cp@ietf.org > >> >> https://www1.ietf.org/mailman/listinfo/l2cp > >> >> > >> > > >> >_______________________________________________ > >> >L2cp mailing list > >> >L2cp@ietf.org > >> >https://www1.ietf.org/mailman/listinfo/l2cp > >> > > >> > >> _______________________________________________ > >> L2cp mailing list > >> L2cp@ietf.org > >> https://www1.ietf.org/mailman/listinfo/l2cp > >> > >> > >> > >--------------------------------------------------------------- > >--------- > >> > >> _______________________________________________ > >> L2cp mailing list > >> L2cp@ietf.org > >> https://www1.ietf.org/mailman/listinfo/l2cp > > >=20 > _______________________________________________ > L2cp mailing list > L2cp@ietf.org > https://www1.ietf.org/mailman/listinfo/l2cp >=20 >=20 > ------------------------------------------------------------------------= >=20 > _______________________________________________ > L2cp mailing list > L2cp@ietf.org > https://www1.ietf.org/mailman/listinfo/l2cp _______________________________________________ L2cp mailing list L2cp@ietf.org https://www1.ietf.org/mailman/listinfo/l2cp _______________________________________________ L2cp mailing list L2cp@ietf.org https://www1.ietf.org/mailman/listinfo/l2cp From l2cp-bounces@ietf.org Tue May 30 07:57:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl2qw-0000gv-3K; Tue, 30 May 2006 07:57:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl2qu-0000gq-BJ for l2cp@ietf.org; Tue, 30 May 2006 07:57:36 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl2qr-0002Mo-F8 for l2cp@ietf.org; Tue, 30 May 2006 07:57:36 -0400 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 May 2006 13:57:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation Date: Tue, 30 May 2006 13:57:25 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [L2CP] RE: Wadhwa new draft 01- Encapsulation Thread-Index: AcaD2N1CYy+xf+dOTfSkmbT0KBJW/gAAxoqA From: "DELAFOY Antoine RD-CORE-LAN" To: "Haag, T" X-OriginalArrivalTime: 30 May 2006 11:57:26.0807 (UTC) FILETIME=[385B7A70:01C683E0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4a96669441ad70ecf6aebb4b47b971cd Cc: l2cp@ietf.org X-BeenThere: l2cp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Layer 2 Control Protocol Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: l2cp-bounces@ietf.org However, if we assume that the NAS should be able to provide QoS for = individual flows and subscribers, it's necessary to provide this = encapsulation. This implies that the NAS would take into account the = overhead on the access loop which depends on both used encapsulation and = IP packet length. Regards, Antoine -----Message d'origine----- De : l2cp-bounces@ietf.org [mailto:l2cp-bounces@ietf.org] De la part de = Haag, T Envoy=E9 : mardi 30 mai 2006 12:49 =C0 : dharkness@juniper.net Cc : l2cp@ietf.org Objet : AW: [L2CP] RE: Wadhwa new draft 01- Encapsulation I share Derek's view. I have some concerns that signalling of the encapsulation will solve the = problem at all because a real impact in shaping and corresponding = overhead is the IP packet length which is not fix. Also to have different encapsulation types (like PPPoE and IPoE) in one = circuit (VLAN or PVC) will not be solved. Regards Thomas -----Urspr=FCngliche Nachricht----- Von: Derek Harkness [mailto:dharkness@juniper.net] Gesendet: Dienstag, 30. Mai 2006 10:11 An: stefaan.de_cnodder@alcatel.be Cc: l2cp@ietf.org Betreff: RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation I understand that if this is a fixed overhead it should be subtracted = from the BW before it is passed in ANCP. However I understood that there = are packet length dependent overheads on the line encoding which cannot = be handled in this way.=20 Cheers, Derek. =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 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+ -----Original Message----- From: stefaan.de_cnodder@alcatel.be [mailto:stefaan.de_cnodder@alcatel.be]=20 Sent: 29 May 2006 14:10 To: Derek Harkness Cc: l2cp@ietf.org Subject: Re: [L2CP] RE: Wadhwa new draft 01- Encapsulation Hi Derek, see below Derek Harkness wrote: > =20 > We have seen this from deployments using VDSL2 DSLAMs. My understanding=20 > is that the overhead is due to the local loop framing which includes=20 > FEC, trellis encoding and other factors. Possibly this can be derived=20 > from the DSL type which we already have in the protocol - I am not=20 > familiar enough with the details of all DSL encodings to be able to=20 > judge that, maybe the access node experts could shed some light here ? > =20 These physical layer overhead cannot be derived from the DSL type=20 because trellis encoding for instance can be switched off or on.=20 However, this overhead of the physical layer is already substracted from the physical bit rate when computing the actual bit rate so I guess=20 there are no issue. regards, Stefaan > Cheers, > =20 > Derek. > =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 > 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:* Michel.Platnic@ecitele.com [mailto:Michel.Platnic@ecitele.com] > *Sent:* 24 May 2006 11:46 > *To:* Sanjay Wadhwa > *Cc:* l2cp@ietf.org > *Subject:* RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation >=20 >=20 > Hi Sanjay and all, > I support Sanjay's proposal to have this encapsulation transported by=20 > ANCP, even if we may argue that > we already have 2 protocols that may transport this information (DHCP=20 > and PPPoE). > About having a different TLV to transport the Encapsulation, it only=20 > partially solves the problem of potentially mixing > layer 1 and layer 2 information. Actually the DSL forum (TR-101) uses=20 > same principle described in your document to transport this > information, it is probably wise to follow the same mechanism.. > Unless other people share this concern, I'll go with your proposal. > Best Regards, > Michel. >=20 >=20 >=20 > *"Sanjay Wadhwa" * >=20 > 24/05/2006 00:01 >=20 > =09 > To > > cc > l2cp@ietf.org > Subject > RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation + Remode Id comments >=20 >=20 > =09 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > >-----Original Message----- > >From: stefaan.de_cnodder@alcatel.be > >[mailto:stefaan.de_cnodder@alcatel.be] > >Sent: Tuesday, May 23, 2006 1:07 PM > >To: Sanjay Wadhwa > >Cc: l2cp@ietf.org > >Subject: Re: [L2CP] RE: Wadhwa new draft 01- Encapsulation + Remode Id > >comments > > > > > > > >Hi Sanjay, > > > >> > >> - Why was the access loop encapsulation object included within a > >> message where all parameters transmitted are layer 1 oriented? > >> There might be several encapsulations available per > >physical link, a > >> new message could maybe better serve the purpose of > >> transmitting the encapsulation parameters. > >> [[SW]] I have sympathy for your arguement as I had a similar > >> concern, which is why L2 encaps has been specified as a > >seprate and > >> optional TLV (although same message). > >> It is to an extent useful for the BNG to learn l2 encaps on the > >> local-loop as it can in some cases allow for more > >accurate shaping > >> of subscriber traffic. > >> > > > >Why not specifying the bandwidth at L2? Then the BNG just takes this > >bandwidth for shaping and it does not have to take care of what > >encapsulation has been used. Why bottering the BNG with the > >encap on the > >DSL line. And what if later someone wants to do the same on non-DSL > >access lines? Are we going to add encap types and updating the > >BNG with > >these new encap types to compute the correct shaping rate? I > >believe it > >would be better to specify the bandwidth at which the BNG has to shape. >=20 > [SW] Shaping on the BNG (based on counting bytes transmitted) needs to > know the "byte adjustment" (under/over-head) due to difference in encaps > on the aggregation network and access loop. I suppose the access-node > could indicate the absolute difference in terms of bytes between the two > encapsulations.. however, this might not be accurate as an aggregation > switch upstream of the DSLAM could change the encaps (e.g. insert an > outer VLAN tag). Ideally, the BNG needs to use the difference between > it's encaps and the encaps on the local-loop. Also, the BNG needs to > adjust for cell-tax if the local-loop is cell based. >=20 > -Sanjay >=20 >=20 > >regards, > >Stefaan > > > > > >> *Chapter 5.4.2* > >> - Typo: > >> Type (Access-Loop-Circuit-ID =3D 0x01) : defined in section 5.4.1 > >> Type (Access-Aggregation-Circuit-ID-Binary =3D 0x02): defined = in > >> section 5.4.1. =20 > >> Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03) : defined = in > >> section 5.4.1. =20 > >> These lines should be updated to comply to Chapter 5.4.1. > >> > >> [[SW]] Will fix. > >> =20 > >> Thanks > >> -Sanjay > >> > >> Thanks and Best Regards, > >> Michel. > >> > >> > >> > >> > >> *"Sanjay Wadhwa" * > >> > >> 05/04/2006 19:22 > >> > >> =20 > >> To > >> "Busschbach, Peter B \(Peter\)" > >, "Wojciech > >> Dec \(wdec\)" , > >> cc > >> =20 > >> Subject > >> RE: [L2CP] Advantages of L2CP (was: Revised WG=20 > Charter Draft) > >> > >> > >> =20 > >> > >> > >> > >> > >> > >> Peter > >> Please see inline.. > >> > >> >-----Original Message----- > >> >From: Busschbach, Peter B (Peter) > >[mailto:busschbach@lucent.com] > >> >Sent: Wednesday, April 05, 2006 10:51 AM > >> >To: 'Wojciech Dec (wdec)'; l2cp@ietf.org > >> >Subject: [L2CP] Advantages of L2CP (was: Revised WG > >Charter Draft) > >> > > >> > > >> >Hi Woj, > >> > > >> >To address the second half of our email exchange: > >> > > >> >I did notice the sentence that addressed Dave's concern. > >> >However, my point was that the charter claims that L2CP will > >> >have a specific benefit ("avoiding complex cross-organization > >> >interactions"), while it is far from clear that in this > >> >respect L2CP is any better than other solutions. > >> > >> [Sanjay] All that the charter is saying is that L2C work > >will undertake > >> use-cases that aim to simplify service management by > >avoiding complex > >> cross-organization interactions. It is a nobel goal that > >L2C is striving > >> to achieve.. What is wrong with that ? This is > >irrespective of wether > >> other solutions can provide this or not. > >> So, as an example, charter for a new dynamic routing > >protocol might say > >> that it will strive to achieve fast network-wide > >convergence (which is a > >> clear benefit over static routing). But, obviously it is > >ok for multiple > >> dynamic routing protocols to work towards this goal and have this > >> explicitly stated in their charter. > >> > >> -Sanjay > >> > >> > >> >I believe that the charter should avoid stating benefits that > >> >are debatable and therefore suggest that the text that I > >> >quoted in my first email be deleted from the charter. > >> > > >> >Peter > >> > > >> >> -----Original Message----- > >> >> From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] > >> >> Sent: Wednesday, April 05, 2006 7:34 AM > >> >> To: Busschbach, Peter B (Peter); l2cp@ietf.org > >> >> Subject: RE: [L2CP] Re: Revised WG Charter Draft > >> >> > >> >> > >> >> Hi Peter, > >> >> > >> >> To address 1) we have put in the following statement > >in the charter > >> >> which you may have not noticed. > >> >> > >> >> "The protocol design will not preclude other uses of L2CP." > >> >> > >> >> WRT 2) we do not lay any claims to how different > >operators structure > >> >> their data bases, and some are probably better at doing it > >> >> than others. > >> >> However it does seem to be a fairly common problem that the > >> >> info related > >> >> to a single subscriber's network service needs to be farmed > >> >> out and fed > >> >> into numerous custom built manager systems besides also the > >> >Radius DB. > >> >> The idea is to allow a mechanism, through the use of L2CP, > >> >to have the > >> >> Access node be provided with such information as and when > >> >> needed by the > >> >> NAS which in turn accesses a common repository like > >a Radius DB. > >> >> Dave's statement was, I believe, in relation to different > >> >> subject; that > >> >> of a wholesale-retail operation, where indeed the > >> >relationship is more > >> >> complex. However we do plan on addressing this as > >evidenced by the > >> >> statement in the charter: > >> >> "L2CP will address security aspects of the control protocol, > >> >including > >> >> the trust model between NAS nodes and access nodes." > >> >> > >> >> Regards, > >> >> Woj. > >> >> > >> >> -----Original Message----- > >> >> From: Busschbach, Peter B (Peter) > >[mailto:busschbach@lucent.com] > >> >> Sent: 04 April 2006 21:23 > >> >> To: 'l2cp@ietf.org' > >> >> Subject: [L2CP] Re: Revised WG Charter Draft > >> >> > >> >> I have two comments on the revised charter. > >> >> > >> >> 1) At the end of the BOF, Mark > >Townsley limited > >> the scope of the > >> >> working group. Unfortunately, this is not captured very > >> >clearly in the > >> >> meeting minutes. The critical sentence in the > >meeting minutes is > >> "DSL > >> >> but good engineers ...". I.e. the focus of the WG is > >to solve a > >> >> particular issue in DSL access networks, but as good > >> >> engineers we should > >> >> not preclude the use of the protocol for other applications. > >> >> > >> >> I don't see the limited scope reflected in the new charter. > >> >> > >> >> 2) Under "Line Configuration". the > >charter says: > >> >> > >> >> > L2CP is intended to simplify the OSS > >infrastructure for service > >> >> > management, allowing subscriber-related service data to be > >> >> maintained > >> >> > in fewer repositories (e.g. RADIUS server back-end > >database) > >> while > >> >> > avoiding complex cross-organization interactions. > >> >> > >> >> I don't understand how L2CP leads to fewer Radius server > >> >back end data > >> >> bases. I also don't understand how L2CP avoids > >cross-organizational > >> >> interactions. There seems to be an assumption that it is ok > >> >> for L2CP to > >> >> cross organizational boundaries but not for other > >protocols. I don't > >> >> think that is correct. At the BOF, Dave Allan pointed out > >> >> that this is > >> >> one of the more difficult problems to solve. Therefore, I > >> >believe that > >> >> this text should be removed from the charter. > >> >> > >> >> Peter > >> >> > >> >> > >> >> > >> >> _______________________________________________ > >> >> L2cp mailing list > >> >> L2cp@ietf.org > >> >> https://www1.ietf.org/mailman/listinfo/l2cp > >> >> > >> > > >> >_______________________________________________ > >> >L2cp mailing list > >> >L2cp@ietf.org > >> >https://www1.ietf.org/mailman/listinfo/l2cp > >> > > >> > >> _______________________________________________ > >> L2cp mailing list > >> L2cp@ietf.org > >> https://www1.ietf.org/mailman/listinfo/l2cp > >> > >> > >> > >--------------------------------------------------------------- > >--------- > >> > >> _______________________________________________ > >> L2cp mailing list > >> L2cp@ietf.org > >> https://www1.ietf.org/mailman/listinfo/l2cp > > >=20 > _______________________________________________ > L2cp mailing list > L2cp@ietf.org > https://www1.ietf.org/mailman/listinfo/l2cp >=20 >=20 > ------------------------------------------------------------------------ >=20 > _______________________________________________ > L2cp mailing list > L2cp@ietf.org > https://www1.ietf.org/mailman/listinfo/l2cp _______________________________________________ L2cp mailing list L2cp@ietf.org https://www1.ietf.org/mailman/listinfo/l2cp _______________________________________________ L2cp mailing list L2cp@ietf.org https://www1.ietf.org/mailman/listinfo/l2cp _______________________________________________ L2cp mailing list L2cp@ietf.org https://www1.ietf.org/mailman/listinfo/l2cp From l2cp-bounces@ietf.org Tue May 30 10:00:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl4mA-0001Xh-Ea; Tue, 30 May 2006 10:00:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl4m9-0001Xc-Jq for l2cp@ietf.org; Tue, 30 May 2006 10:00:49 -0400 Received: from smail.alcatel.fr ([64.208.49.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl4m4-00052X-Pc for l2cp@ietf.org; Tue, 30 May 2006 10:00:49 -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 k4UE0Xps026842; Tue, 30 May 2006 16:00:33 +0200 Received: from [138.203.192.250] ([138.203.192.250]) by bemail06.netfr.alcatel.fr (Lotus Domino Release 5.0.12HF868) with ESMTP id 2006053016003129:4082 ; Tue, 30 May 2006 16:00:31 +0200 Message-ID: <447C4FFE.5020403@alcatel.be> Date: Tue, 30 May 2006 16:00:30 +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: Derek Harkness Subject: Re: [L2CP] RE: Wadhwa new draft 01- Encapsulation References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 05/30/2006 16:00:31, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 05/30/2006 16:00:33, Serialize complete at 05/30/2006 16:00: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: 64b72a8e61417554b4b727cb14e7034d Cc: l2cp@ietf.org X-BeenThere: l2cp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Layer 2 Control Protocol Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: l2cp-bounces@ietf.org Hi Derek, Indeed, although some parts of the overhead are already substracted from the data rate by the DSLAM, it seems there is more overhead (frame length depending) on the physical layer that is not yet substracted. regards, Stefaan Derek Harkness wrote: > I understand that if this is a fixed overhead it should be subtracted > from the BW before it is passed in ANCP. However I understood that there > are packet length dependent overheads on the line encoding which cannot > be handled in this way. > > Cheers, > > Derek. > > > > > +=============================+ > Derek Harkness > Systems Engineer > Juniper Networks > Nymphenburger Strasse 13-15 > 80335 Munich > Germany > Tel: +49 89 5529 4916 > Mobile: +49 172 843 6621 > Email: DHarkness@juniper.net > +=============================+ > > > -----Original Message----- > From: stefaan.de_cnodder@alcatel.be > [mailto:stefaan.de_cnodder@alcatel.be] > Sent: 29 May 2006 14:10 > To: Derek Harkness > Cc: l2cp@ietf.org > Subject: Re: [L2CP] RE: Wadhwa new draft 01- Encapsulation > > > Hi Derek, > > see below > > Derek Harkness wrote: > > >> >>We have seen this from deployments using VDSL2 DSLAMs. My > > understanding > >>is that the overhead is due to the local loop framing which includes >>FEC, trellis encoding and other factors. Possibly this can be derived >>from the DSL type which we already have in the protocol - I am not >>familiar enough with the details of all DSL encodings to be able to >>judge that, maybe the access node experts could shed some light here ? >> > > > These physical layer overhead cannot be derived from the DSL type > because trellis encoding for instance can be switched off or on. > However, this overhead of the physical layer is already substracted from > > the physical bit rate when computing the actual bit rate so I guess > there are no issue. > > regards, > Stefaan > > > > >>Cheers, >> >> Derek. >> >> >>+=============================+ >>Derek Harkness >>Systems Engineer >>Juniper Networks >>Nymphenburger Strasse 13-15 >>80335 Munich >>Germany >>Tel: +49 89 5529 4916 >>Mobile: +49 172 843 6621 >>Email: DHarkness@juniper.net >>+=============================+ >> >> >> > > ------------------------------------------------------------------------ > >>*From:* Michel.Platnic@ecitele.com [mailto:Michel.Platnic@ecitele.com] >>*Sent:* 24 May 2006 11:46 >>*To:* Sanjay Wadhwa >>*Cc:* l2cp@ietf.org >>*Subject:* RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation >> >> >>Hi Sanjay and all, >>I support Sanjay's proposal to have this encapsulation transported by >>ANCP, even if we may argue that >>we already have 2 protocols that may transport this information (DHCP >>and PPPoE). >>About having a different TLV to transport the Encapsulation, it only >>partially solves the problem of potentially mixing >>layer 1 and layer 2 information. Actually the DSL forum (TR-101) uses >>same principle described in your document to transport this >>information, it is probably wise to follow the same mechanism.. >>Unless other people share this concern, I'll go with your proposal. >>Best Regards, >>Michel. >> >> >> >>*"Sanjay Wadhwa" * >> >>24/05/2006 00:01 >> >> >>To >> >>cc >> l2cp@ietf.org >>Subject >> RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation + Remode Id > > comments > >> >> >> >> >> >> >> >> >> >> >-----Original Message----- >> >From: stefaan.de_cnodder@alcatel.be >> >[mailto:stefaan.de_cnodder@alcatel.be] >> >Sent: Tuesday, May 23, 2006 1:07 PM >> >To: Sanjay Wadhwa >> >Cc: l2cp@ietf.org >> >Subject: Re: [L2CP] RE: Wadhwa new draft 01- Encapsulation + Remode > > Id > >> >comments >> > >> > >> > >> >Hi Sanjay, >> > >> >> >> >> - Why was the access loop encapsulation object included within > > a > >> >> message where all parameters transmitted are layer 1 oriented? >> >> There might be several encapsulations available per >> >physical link, a >> >> new message could maybe better serve the purpose of >> >> transmitting the encapsulation parameters. >> >> [[SW]] I have sympathy for your arguement as I had a similar >> >> concern, which is why L2 encaps has been specified as a >> >seprate and >> >> optional TLV (although same message). >> >> It is to an extent useful for the BNG to learn l2 encaps on > > the > >> >> local-loop as it can in some cases allow for more >> >accurate shaping >> >> of subscriber traffic. >> >> >> > >> >Why not specifying the bandwidth at L2? Then the BNG just takes this >> >bandwidth for shaping and it does not have to take care of what >> >encapsulation has been used. Why bottering the BNG with the >> >encap on the >> >DSL line. And what if later someone wants to do the same on non-DSL >> >access lines? Are we going to add encap types and updating the >> >BNG with >> >these new encap types to compute the correct shaping rate? I >> >believe it >> >would be better to specify the bandwidth at which the BNG has to > > shape. > >>[SW] Shaping on the BNG (based on counting bytes transmitted) needs to >>know the "byte adjustment" (under/over-head) due to difference in > > encaps > >>on the aggregation network and access loop. I suppose the access-node >>could indicate the absolute difference in terms of bytes between the > > two > >>encapsulations.. however, this might not be accurate as an aggregation >>switch upstream of the DSLAM could change the encaps (e.g. insert an >>outer VLAN tag). Ideally, the BNG needs to use the difference between >>it's encaps and the encaps on the local-loop. Also, the BNG needs to >>adjust for cell-tax if the local-loop is cell based. >> >>-Sanjay >> >> >> >regards, >> >Stefaan >> > >> > >> >> *Chapter 5.4.2* >> >> - Typo: >> >> Type (Access-Loop-Circuit-ID = 0x01) : defined in section > > 5.4.1 > >> >> Type (Access-Aggregation-Circuit-ID-Binary = 0x02): defined in >> >> section 5.4.1. >> >> Type (Access-Aggregation-Circuit-ID-ASCII = 0x03) : defined in >> >> section 5.4.1. >> >> These lines should be updated to comply to Chapter 5.4.1. >> >> >> >> [[SW]] Will fix. >> >> >> >> Thanks >> >> -Sanjay >> >> >> >> Thanks and Best Regards, >> >> Michel. >> >> >> >> >> >> >> >> >> >> *"Sanjay Wadhwa" * >> >> >> >> 05/04/2006 19:22 >> >> >> >> >> >> To >> >> "Busschbach, Peter B \(Peter\)" >> >, "Wojciech >> >> Dec \(wdec\)" , >> >> cc >> >> >> >> Subject >> >> RE: [L2CP] Advantages of L2CP (was: Revised > > WG > >>Charter Draft) >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Peter >> >> Please see inline.. >> >> >> >> >-----Original Message----- >> >> >From: Busschbach, Peter B (Peter) >> >[mailto:busschbach@lucent.com] >> >> >Sent: Wednesday, April 05, 2006 10:51 AM >> >> >To: 'Wojciech Dec (wdec)'; l2cp@ietf.org >> >> >Subject: [L2CP] Advantages of L2CP (was: Revised WG >> >Charter Draft) >> >> > >> >> > >> >> >Hi Woj, >> >> > >> >> >To address the second half of our email exchange: >> >> > >> >> >I did notice the sentence that addressed Dave's concern. >> >> >However, my point was that the charter claims that L2CP will >> >> >have a specific benefit ("avoiding complex > > cross-organization > >> >> >interactions"), while it is far from clear that in this >> >> >respect L2CP is any better than other solutions. >> >> >> >> [Sanjay] All that the charter is saying is that L2C work >> >will undertake >> >> use-cases that aim to simplify service management by >> >avoiding complex >> >> cross-organization interactions. It is a nobel goal that >> >L2C is striving >> >> to achieve.. What is wrong with that ? This is >> >irrespective of wether >> >> other solutions can provide this or not. >> >> So, as an example, charter for a new dynamic routing >> >protocol might say >> >> that it will strive to achieve fast network-wide >> >convergence (which is a >> >> clear benefit over static routing). But, obviously it is >> >ok for multiple >> >> dynamic routing protocols to work towards this goal and have > > this > >> >> explicitly stated in their charter. >> >> >> >> -Sanjay >> >> >> >> >> >> >I believe that the charter should avoid stating benefits > > that > >> >> >are debatable and therefore suggest that the text that I >> >> >quoted in my first email be deleted from the charter. >> >> > >> >> >Peter >> >> > >> >> >> -----Original Message----- >> >> >> From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] >> >> >> Sent: Wednesday, April 05, 2006 7:34 AM >> >> >> To: Busschbach, Peter B (Peter); l2cp@ietf.org >> >> >> Subject: RE: [L2CP] Re: Revised WG Charter Draft >> >> >> >> >> >> >> >> >> Hi Peter, >> >> >> >> >> >> To address 1) we have put in the following statement >> >in the charter >> >> >> which you may have not noticed. >> >> >> >> >> >> "The protocol design will not preclude other uses of > > L2CP." > >> >> >> >> >> >> WRT 2) we do not lay any claims to how different >> >operators structure >> >> >> their data bases, and some are probably better at doing it >> >> >> than others. >> >> >> However it does seem to be a fairly common problem that > > the > >> >> >> info related >> >> >> to a single subscriber's network service needs to be > > farmed > >> >> >> out and fed >> >> >> into numerous custom built manager systems besides also > > the > >> >> >Radius DB. >> >> >> The idea is to allow a mechanism, through the use of L2CP, >> >> >to have the >> >> >> Access node be provided with such information as and when >> >> >> needed by the >> >> >> NAS which in turn accesses a common repository like >> >a Radius DB. >> >> >> Dave's statement was, I believe, in relation to different >> >> >> subject; that >> >> >> of a wholesale-retail operation, where indeed the >> >> >relationship is more >> >> >> complex. However we do plan on addressing this as >> >evidenced by the >> >> >> statement in the charter: >> >> >> "L2CP will address security aspects of the control > > protocol, > >> >> >including >> >> >> the trust model between NAS nodes and access nodes." >> >> >> >> >> >> Regards, >> >> >> Woj. >> >> >> >> >> >> -----Original Message----- >> >> >> From: Busschbach, Peter B (Peter) >> >[mailto:busschbach@lucent.com] >> >> >> Sent: 04 April 2006 21:23 >> >> >> To: 'l2cp@ietf.org' >> >> >> Subject: [L2CP] Re: Revised WG Charter Draft >> >> >> >> >> >> I have two comments on the revised charter. >> >> >> >> >> >> 1) At the end of the BOF, Mark >> >Townsley limited >> >> the scope of the >> >> >> working group. Unfortunately, this is not captured very >> >> >clearly in the >> >> >> meeting minutes. The critical sentence in the >> >meeting minutes is >> >> "DSL >> >> >> but good engineers ...". I.e. the focus of the WG is >> >to solve a >> >> >> particular issue in DSL access networks, but as good >> >> >> engineers we should >> >> >> not preclude the use of the protocol for other > > applications. > >> >> >> >> >> >> I don't see the limited scope reflected in the new > > charter. > >> >> >> >> >> >> 2) Under "Line Configuration". the >> >charter says: >> >> >> >> >> >> > L2CP is intended to simplify the OSS >> >infrastructure for service >> >> >> > management, allowing subscriber-related service data to > > be > >> >> >> maintained >> >> >> > in fewer repositories (e.g. RADIUS server back-end >> >database) >> >> while >> >> >> > avoiding complex cross-organization interactions. >> >> >> >> >> >> I don't understand how L2CP leads to fewer Radius server >> >> >back end data >> >> >> bases. I also don't understand how L2CP avoids >> >cross-organizational >> >> >> interactions. There seems to be an assumption that it is > > ok > >> >> >> for L2CP to >> >> >> cross organizational boundaries but not for other >> >protocols. I don't >> >> >> think that is correct. At the BOF, Dave Allan pointed out > > >> >> >> that this is >> >> >> one of the more difficult problems to solve. Therefore, I >> >> >believe that >> >> >> this text should be removed from the charter. >> >> >> >> >> >> Peter >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> L2cp mailing list >> >> >> L2cp@ietf.org >> >> >> https://www1.ietf.org/mailman/listinfo/l2cp >> >> >> >> >> > >> >> >_______________________________________________ >> >> >L2cp mailing list >> >> >L2cp@ietf.org >> >> >https://www1.ietf.org/mailman/listinfo/l2cp >> >> > >> >> >> >> _______________________________________________ >> >> L2cp mailing list >> >> L2cp@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/l2cp >> >> >> >> >> >> >> >--------------------------------------------------------------- >> >--------- >> >> >> >> _______________________________________________ >> >> L2cp mailing list >> >> L2cp@ietf.org >> >> https://www1.ietf.org/mailman/listinfo/l2cp >> > >> >>_______________________________________________ >>L2cp mailing list >>L2cp@ietf.org >>https://www1.ietf.org/mailman/listinfo/l2cp >> >> >> > > ------------------------------------------------------------------------ > >>_______________________________________________ >>L2cp mailing list >>L2cp@ietf.org >>https://www1.ietf.org/mailman/listinfo/l2cp > > _______________________________________________ L2cp mailing list L2cp@ietf.org https://www1.ietf.org/mailman/listinfo/l2cp From l2cp-bounces@ietf.org Tue May 30 18:52:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlD4d-00052X-O1; Tue, 30 May 2006 18:52:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlD4a-0004xY-VH for l2cp@ietf.org; Tue, 30 May 2006 18:52:25 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlD4a-0006a8-3U for l2cp@ietf.org; Tue, 30 May 2006 18:52:24 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 84763C1C326; Tue, 30 May 2006 15:52:21 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18818-06; Tue, 30 May 2006 15:52:21 -0700 (PDT) Received: from [127.0.0.1] (login005.redback.com [155.53.12.64]) by prattle.redback.com (Postfix) with ESMTP id 4C967C1C327; Tue, 30 May 2006 15:52:21 -0700 (PDT) Message-ID: <447CCCE8.5000304@redback.com> Date: Tue, 30 May 2006 15:53:28 -0700 From: Jakob Heitz Organization: Redback Networks, Software Development User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Haag, T" , l2cp@ietf.org Subject: Re: AW: [L2CP] RE: Wadhwa new draft 01- Encapsulation References: <6439282641581441A36F7F6F83ED2ED287CEDD@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <6439282641581441A36F7F6F83ED2ED287CEDD@S4DE8PSAAFQ.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: by amavisd-new at redback.com Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 8da0cbf8c1eef8eab03772f2044efec0 Cc: X-BeenThere: l2cp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Layer 2 Control Protocol Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: l2cp-bounces@ietf.org Haag, T wrote: > I share Derek's view. >=20 > I have some concerns that signalling of the encapsulation will solve th= e problem at all because a real impact in shaping and corresponding overh= ead is the IP packet length which is not fix. The shapers and rate-limiters know the length of packets. They can count the bytes in a packet and add a fixed overhead per packet. They can even account for ATM cell overhead, even when an ATM cell is only partially used. The only problem I see is to tell the shaper the properties of the line. That problem can be solved. Does this address your concerns? >=20 > Also to have different encapsulation types (like PPPoE and IPoE) in one= circuit (VLAN or PVC) will not be solved. If the per-packet overhead is the same for PPPoE and IPoE, then the problem is trivial. If not, then the problem is merely a little harder, but can still be solved. The only question I have is how do we find out what that overhead is. Why do you think the problem will not be solved? >=20 > Regards > Thomas >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: Derek Harkness [mailto:dharkness@juniper.net]=20 > Gesendet: Dienstag, 30. Mai 2006 10:11 > An: stefaan.de_cnodder@alcatel.be > Cc: l2cp@ietf.org > Betreff: RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation >=20 > I understand that if this is a fixed overhead it should be subtracted > from the BW before it is passed in ANCP. However I understood that ther= e > are packet length dependent overheads on the line encoding which cannot > be handled in this way.=20 >=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 >=20 > -----Original Message----- > From: stefaan.de_cnodder@alcatel.be > [mailto:stefaan.de_cnodder@alcatel.be]=20 > Sent: 29 May 2006 14:10 > To: Derek Harkness > Cc: l2cp@ietf.org > Subject: Re: [L2CP] RE: Wadhwa new draft 01- Encapsulation >=20 >=20 > Hi Derek, >=20 > see below >=20 > Derek Harkness wrote: >=20 >=20 >>=20 >>We have seen this from deployments using VDSL2 DSLAMs. My >=20 > understanding=20 >=20 >>is that the overhead is due to the local loop framing which includes=20 >>FEC, trellis encoding and other factors. Possibly this can be derived=20 >>from the DSL type which we already have in the protocol - I am not=20 >>familiar enough with the details of all DSL encodings to be able to=20 >>judge that, maybe the access node experts could shed some light here ? >>=20 >=20 >=20 > These physical layer overhead cannot be derived from the DSL type=20 > because trellis encoding for instance can be switched off or on.=20 > However, this overhead of the physical layer is already substracted fro= m >=20 > the physical bit rate when computing the actual bit rate so I guess=20 > there are no issue. >=20 > regards, > Stefaan >=20 >=20 >=20 >=20 >>Cheers, >>=20 >> Derek. >>=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 >>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 > -----------------------------------------------------------------------= - >=20 >>*From:* Michel.Platnic@ecitele.com [mailto:Michel.Platnic@ecitele.com] >>*Sent:* 24 May 2006 11:46 >>*To:* Sanjay Wadhwa >>*Cc:* l2cp@ietf.org >>*Subject:* RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation >> >> >>Hi Sanjay and all, >>I support Sanjay's proposal to have this encapsulation transported by=20 >>ANCP, even if we may argue that >>we already have 2 protocols that may transport this information (DHCP=20 >>and PPPoE). >>About having a different TLV to transport the Encapsulation, it only=20 >>partially solves the problem of potentially mixing >>layer 1 and layer 2 information. Actually the DSL forum (TR-101) uses=20 >>same principle described in your document to transport this >>information, it is probably wise to follow the same mechanism.. >>Unless other people share this concern, I'll go with your proposal. >>Best Regards, >>Michel. >> >> >> >>*"Sanjay Wadhwa" * >> >>24/05/2006 00:01 >> >>=09 >>To >> >>cc >> l2cp@ietf.org >>Subject >> RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation + Remode Id >=20 > comments >=20 >> >>=09 >> >> >> >> >> >> >> >> >-----Original Message----- >> >From: stefaan.de_cnodder@alcatel.be >> >[mailto:stefaan.de_cnodder@alcatel.be] >> >Sent: Tuesday, May 23, 2006 1:07 PM >> >To: Sanjay Wadhwa >> >Cc: l2cp@ietf.org >> >Subject: Re: [L2CP] RE: Wadhwa new draft 01- Encapsulation + Remode >=20 > Id >=20 >> >comments >> > >> > >> > >> >Hi Sanjay, >> > >> >> >> >> - Why was the access loop encapsulation object included within >=20 > a >=20 >> >> message where all parameters transmitted are layer 1 oriented? >> >> There might be several encapsulations available per >> >physical link, a >> >> new message could maybe better serve the purpose of >> >> transmitting the encapsulation parameters. >> >> [[SW]] I have sympathy for your arguement as I had a similar >> >> concern, which is why L2 encaps has been specified as a >> >seprate and >> >> optional TLV (although same message). >> >> It is to an extent useful for the BNG to learn l2 encaps on >=20 > the >=20 >> >> local-loop as it can in some cases allow for more >> >accurate shaping >> >> of subscriber traffic. >> >> >> > >> >Why not specifying the bandwidth at L2? Then the BNG just takes this >> >bandwidth for shaping and it does not have to take care of what >> >encapsulation has been used. Why bottering the BNG with the >> >encap on the >> >DSL line. And what if later someone wants to do the same on non-DSL >> >access lines? Are we going to add encap types and updating the >> >BNG with >> >these new encap types to compute the correct shaping rate? I >> >believe it >> >would be better to specify the bandwidth at which the BNG has to >=20 > shape. >=20 >>[SW] Shaping on the BNG (based on counting bytes transmitted) needs to >>know the "byte adjustment" (under/over-head) due to difference in >=20 > encaps >=20 >>on the aggregation network and access loop. I suppose the access-node >>could indicate the absolute difference in terms of bytes between the >=20 > two >=20 >>encapsulations.. however, this might not be accurate as an aggregation >>switch upstream of the DSLAM could change the encaps (e.g. insert an >>outer VLAN tag). Ideally, the BNG needs to use the difference between >>it's encaps and the encaps on the local-loop. Also, the BNG needs to >>adjust for cell-tax if the local-loop is cell based. >> >>-Sanjay >> >> >> >regards, >> >Stefaan >> > >> > >> >> *Chapter 5.4.2* >> >> - Typo: >> >> Type (Access-Loop-Circuit-ID =3D 0x01) : defined in section >=20 > 5.4.1 >=20 >> >> Type (Access-Aggregation-Circuit-ID-Binary =3D 0x02): defined i= n >> >> section 5.4.1. =20 >> >> Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03) : defined i= n >> >> section 5.4.1. =20 >> >> These lines should be updated to comply to Chapter 5.4.1. >> >> >> >> [[SW]] Will fix. >> >> =20 >> >> Thanks >> >> -Sanjay >> >> >> >> Thanks and Best Regards, >> >> Michel. >> >> >> >> >> >> >> >> >> >> *"Sanjay Wadhwa" * >> >> >> >> 05/04/2006 19:22 >> >> >> >> =20 >> >> To >> >> "Busschbach, Peter B \(Peter\)" >> >, "Wojciech >> >> Dec \(wdec\)" , >> >> cc >> >> =20 >> >> Subject >> >> RE: [L2CP] Advantages of L2CP (was: Revised >=20 > WG=20 >=20 >>Charter Draft) >> >> >> >> >> >> =20 >> >> >> >> >> >> >> >> >> >> >> >> Peter >> >> Please see inline.. >> >> >> >> >-----Original Message----- >> >> >From: Busschbach, Peter B (Peter) >> >[mailto:busschbach@lucent.com] >> >> >Sent: Wednesday, April 05, 2006 10:51 AM >> >> >To: 'Wojciech Dec (wdec)'; l2cp@ietf.org >> >> >Subject: [L2CP] Advantages of L2CP (was: Revised WG >> >Charter Draft) >> >> > >> >> > >> >> >Hi Woj, >> >> > >> >> >To address the second half of our email exchange: >> >> > >> >> >I did notice the sentence that addressed Dave's concern. >> >> >However, my point was that the charter claims that L2CP will >> >> >have a specific benefit ("avoiding complex >=20 > cross-organization >=20 >> >> >interactions"), while it is far from clear that in this >> >> >respect L2CP is any better than other solutions. >> >> >> >> [Sanjay] All that the charter is saying is that L2C work >> >will undertake >> >> use-cases that aim to simplify service management by >> >avoiding complex >> >> cross-organization interactions. It is a nobel goal that >> >L2C is striving >> >> to achieve.. What is wrong with that ? This is >> >irrespective of wether >> >> other solutions can provide this or not. >> >> So, as an example, charter for a new dynamic routing >> >protocol might say >> >> that it will strive to achieve fast network-wide >> >convergence (which is a >> >> clear benefit over static routing). But, obviously it is >> >ok for multiple >> >> dynamic routing protocols to work towards this goal and have >=20 > this >=20 >> >> explicitly stated in their charter. >> >> >> >> -Sanjay >> >> >> >> >> >> >I believe that the charter should avoid stating benefits >=20 > that >=20 >> >> >are debatable and therefore suggest that the text that I >> >> >quoted in my first email be deleted from the charter. >> >> > >> >> >Peter >> >> > >> >> >> -----Original Message----- >> >> >> From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] >> >> >> Sent: Wednesday, April 05, 2006 7:34 AM >> >> >> To: Busschbach, Peter B (Peter); l2cp@ietf.org >> >> >> Subject: RE: [L2CP] Re: Revised WG Charter Draft >> >> >> >> >> >> >> >> >> Hi Peter, >> >> >> >> >> >> To address 1) we have put in the following statement >> >in the charter >> >> >> which you may have not noticed. >> >> >> >> >> >> "The protocol design will not preclude other uses of >=20 > L2CP." >=20 >> >> >> >> >> >> WRT 2) we do not lay any claims to how different >> >operators structure >> >> >> their data bases, and some are probably better at doing it >> >> >> than others. >> >> >> However it does seem to be a fairly common problem that >=20 > the >=20 >> >> >> info related >> >> >> to a single subscriber's network service needs to be >=20 > farmed >=20 >> >> >> out and fed >> >> >> into numerous custom built manager systems besides also >=20 > the >=20 >> >> >Radius DB. >> >> >> The idea is to allow a mechanism, through the use of L2CP, >> >> >to have the >> >> >> Access node be provided with such information as and when >> >> >> needed by the >> >> >> NAS which in turn accesses a common repository like >> >a Radius DB. >> >> >> Dave's statement was, I believe, in relation to different >> >> >> subject; that >> >> >> of a wholesale-retail operation, where indeed the >> >> >relationship is more >> >> >> complex. However we do plan on addressing this as >> >evidenced by the >> >> >> statement in the charter: >> >> >> "L2CP will address security aspects of the control >=20 > protocol, >=20 >> >> >including >> >> >> the trust model between NAS nodes and access nodes." >> >> >> >> >> >> Regards, >> >> >> Woj. >> >> >> >> >> >> -----Original Message----- >> >> >> From: Busschbach, Peter B (Peter) >> >[mailto:busschbach@lucent.com] >> >> >> Sent: 04 April 2006 21:23 >> >> >> To: 'l2cp@ietf.org' >> >> >> Subject: [L2CP] Re: Revised WG Charter Draft >> >> >> >> >> >> I have two comments on the revised charter. >> >> >> >> >> >> 1) At the end of the BOF, Mark >> >Townsley limited >> >> the scope of the >> >> >> working group. Unfortunately, this is not captured very >> >> >clearly in the >> >> >> meeting minutes. The critical sentence in the >> >meeting minutes is >> >> "DSL >> >> >> but good engineers ...". I.e. the focus of the WG is >> >to solve a >> >> >> particular issue in DSL access networks, but as good >> >> >> engineers we should >> >> >> not preclude the use of the protocol for other >=20 > applications. >=20 >> >> >> >> >> >> I don't see the limited scope reflected in the new >=20 > charter. >=20 >> >> >> >> >> >> 2) Under "Line Configuration". the >> >charter says: >> >> >> >> >> >> > L2CP is intended to simplify the OSS >> >infrastructure for service >> >> >> > management, allowing subscriber-related service data to >=20 > be >=20 >> >> >> maintained >> >> >> > in fewer repositories (e.g. RADIUS server back-end >> >database) >> >> while >> >> >> > avoiding complex cross-organization interactions. >> >> >> >> >> >> I don't understand how L2CP leads to fewer Radius server >> >> >back end data >> >> >> bases. I also don't understand how L2CP avoids >> >cross-organizational >> >> >> interactions. There seems to be an assumption that it is >=20 > ok >=20 >> >> >> for L2CP to >> >> >> cross organizational boundaries but not for other >> >protocols. I don't >> >> >> think that is correct. At the BOF, Dave Allan pointed out >=20 >=20 >> >> >> that this is >> >> >> one of the more difficult problems to solve. Therefore, I >> >> >believe that >> >> >> this text should be removed from the charter. >> >> >> >> >> >> Peter --=20 Jakob Heitz. _______________________________________________ L2cp mailing list L2cp@ietf.org https://www1.ietf.org/mailman/listinfo/l2cp From l2cp-bounces@ietf.org Wed May 31 03:27:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlL6c-0002P5-3r; Wed, 31 May 2006 03:27:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlL6b-0002Oz-E6 for l2cp@ietf.org; Wed, 31 May 2006 03:27:01 -0400 Received: from tcmail33.telekom.de ([217.6.95.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlL6a-0003pX-Kc for l2cp@ietf.org; Wed, 31 May 2006 03:27:01 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.dmz.telekom.de with ESMTP; Wed, 31 May 2006 09:26:58 +0200 Received: by S4DE8PSAANS.blf.telekom.de with Internet Mail Service (5.5.2653.19) id ; Wed, 31 May 2006 09:26:58 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED287CEE2@S4DE8PSAAFQ.mitte.t-com.de> From: "Haag, T" To: jheitz@redback.com Subject: AW: AW: [L2CP] RE: Wadhwa new draft 01- Encapsulation Date: Wed, 31 May 2006 09:26:53 +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: 7191030d885084e634ab0f488bcd9d53 Cc: l2cp@ietf.org X-BeenThere: l2cp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Layer 2 Control Protocol Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: l2cp-bounces@ietf.org Jakob, May be I'm wrong but my understanding is as follows: If a customer connection is installed the BRAS has to be configured. = This include beside L2 circuit ID the encapsulation any way. So the = BRAS knew from the beginning which encapsulation type is used. So I = think having an encapsulation information is redundant because the = shaper implementation in the BRAS is independent on having the = encapsulation type or not. The shaper has to adapt/adjust to the given = configuration any way. Imagine the case to have more than one encapsulation type running over = the same L2 circuit (e.g. PPPoE & IPoE). Which encapsulation type is = reported? As far as I learned it is not possible to do this. Regards Thomas -----Urspr=FCngliche Nachricht----- Von: Jakob Heitz [mailto:jheitz@redback.com]=20 Gesendet: Mittwoch, 31. Mai 2006 00:53 An: Haag, Thomas; l2cp@ietf.org Betreff: Re: AW: [L2CP] RE: Wadhwa new draft 01- Encapsulation Haag, T wrote: > I share Derek's view. >=20 > I have some concerns that signalling of the encapsulation will solve = the problem at all because a real impact in shaping and corresponding = overhead is the IP packet length which is not fix. The shapers and rate-limiters know the length of packets. They can count the bytes in a packet and add a fixed overhead per packet. They can even account for ATM cell overhead, even when an ATM cell is only partially used. The only problem I see is to tell the shaper the properties of the line. That problem can be solved. Does this address your concerns? >=20 > Also to have different encapsulation types (like PPPoE and IPoE) in = one circuit (VLAN or PVC) will not be solved. If the per-packet overhead is the same for PPPoE and IPoE, then the problem is trivial. If not, then the problem is merely a little harder, but can still be solved. The only question I have is how do we find out what that overhead is. Why do you think the problem will not be solved? >=20 > Regards > Thomas >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: Derek Harkness [mailto:dharkness@juniper.net]=20 > Gesendet: Dienstag, 30. Mai 2006 10:11 > An: stefaan.de_cnodder@alcatel.be > Cc: l2cp@ietf.org > Betreff: RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation >=20 > I understand that if this is a fixed overhead it should be subtracted > from the BW before it is passed in ANCP. However I understood that = there > are packet length dependent overheads on the line encoding which = cannot > be handled in this way.=20 >=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 >=20 > -----Original Message----- > From: stefaan.de_cnodder@alcatel.be > [mailto:stefaan.de_cnodder@alcatel.be]=20 > Sent: 29 May 2006 14:10 > To: Derek Harkness > Cc: l2cp@ietf.org > Subject: Re: [L2CP] RE: Wadhwa new draft 01- Encapsulation >=20 >=20 > Hi Derek, >=20 > see below >=20 > Derek Harkness wrote: >=20 >=20 >>=20 >>We have seen this from deployments using VDSL2 DSLAMs. My >=20 > understanding=20 >=20 >>is that the overhead is due to the local loop framing which includes=20 >>FEC, trellis encoding and other factors. Possibly this can be derived = >>from the DSL type which we already have in the protocol - I am not=20 >>familiar enough with the details of all DSL encodings to be able to=20 >>judge that, maybe the access node experts could shed some light here = ? >>=20 >=20 >=20 > These physical layer overhead cannot be derived from the DSL type=20 > because trellis encoding for instance can be switched off or on.=20 > However, this overhead of the physical layer is already substracted = from >=20 > the physical bit rate when computing the actual bit rate so I guess=20 > there are no issue. >=20 > regards, > Stefaan >=20 >=20 >=20 >=20 >>Cheers, >>=20 >> Derek. >>=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 >>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 > = ------------------------------------------------------------------------= >=20 >>*From:* Michel.Platnic@ecitele.com = [mailto:Michel.Platnic@ecitele.com] >>*Sent:* 24 May 2006 11:46 >>*To:* Sanjay Wadhwa >>*Cc:* l2cp@ietf.org >>*Subject:* RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation >> >> >>Hi Sanjay and all, >>I support Sanjay's proposal to have this encapsulation transported by = >>ANCP, even if we may argue that >>we already have 2 protocols that may transport this information (DHCP = >>and PPPoE). >>About having a different TLV to transport the Encapsulation, it only=20 >>partially solves the problem of potentially mixing >>layer 1 and layer 2 information. Actually the DSL forum (TR-101) uses = >>same principle described in your document to transport this >>information, it is probably wise to follow the same mechanism.. >>Unless other people share this concern, I'll go with your proposal. >>Best Regards, >>Michel. >> >> >> >>*"Sanjay Wadhwa" * >> >>24/05/2006 00:01 >> >>=09 >>To >> >>cc >> l2cp@ietf.org >>Subject >> RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation + Remode Id >=20 > comments >=20 >> >>=09 >> >> >> >> >> >> >> >> >-----Original Message----- >> >From: stefaan.de_cnodder@alcatel.be >> >[mailto:stefaan.de_cnodder@alcatel.be] >> >Sent: Tuesday, May 23, 2006 1:07 PM >> >To: Sanjay Wadhwa >> >Cc: l2cp@ietf.org >> >Subject: Re: [L2CP] RE: Wadhwa new draft 01- Encapsulation + Remode >=20 > Id >=20 >> >comments >> > >> > >> > >> >Hi Sanjay, >> > >> >> >> >> - Why was the access loop encapsulation object included = within >=20 > a >=20 >> >> message where all parameters transmitted are layer 1 = oriented? >> >> There might be several encapsulations available per >> >physical link, a >> >> new message could maybe better serve the purpose of >> >> transmitting the encapsulation parameters. >> >> [[SW]] I have sympathy for your arguement as I had a similar >> >> concern, which is why L2 encaps has been specified as a >> >seprate and >> >> optional TLV (although same message). >> >> It is to an extent useful for the BNG to learn l2 encaps on >=20 > the >=20 >> >> local-loop as it can in some cases allow for more >> >accurate shaping >> >> of subscriber traffic. >> >> >> > >> >Why not specifying the bandwidth at L2? Then the BNG just takes = this >> >bandwidth for shaping and it does not have to take care of what >> >encapsulation has been used. Why bottering the BNG with the >> >encap on the >> >DSL line. And what if later someone wants to do the same on non-DSL >> >access lines? Are we going to add encap types and updating the >> >BNG with >> >these new encap types to compute the correct shaping rate? I >> >believe it >> >would be better to specify the bandwidth at which the BNG has to >=20 > shape. >=20 >>[SW] Shaping on the BNG (based on counting bytes transmitted) needs = to >>know the "byte adjustment" (under/over-head) due to difference in >=20 > encaps >=20 >>on the aggregation network and access loop. I suppose the access-node >>could indicate the absolute difference in terms of bytes between the >=20 > two >=20 >>encapsulations.. however, this might not be accurate as an = aggregation >>switch upstream of the DSLAM could change the encaps (e.g. insert an >>outer VLAN tag). Ideally, the BNG needs to use the difference between >>it's encaps and the encaps on the local-loop. Also, the BNG needs to >>adjust for cell-tax if the local-loop is cell based. >> >>-Sanjay >> >> >> >regards, >> >Stefaan >> > >> > >> >> *Chapter 5.4.2* >> >> - Typo: >> >> Type (Access-Loop-Circuit-ID =3D 0x01) : defined in section >=20 > 5.4.1 >=20 >> >> Type (Access-Aggregation-Circuit-ID-Binary =3D 0x02): defined = in >> >> section 5.4.1. =20 >> >> Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03) : defined = in >> >> section 5.4.1. =20 >> >> These lines should be updated to comply to Chapter 5.4.1. >> >> >> >> [[SW]] Will fix. >> >> =20 >> >> Thanks >> >> -Sanjay >> >> >> >> Thanks and Best Regards, >> >> Michel. >> >> >> >> >> >> >> >> >> >> *"Sanjay Wadhwa" * >> >> >> >> 05/04/2006 19:22 >> >> >> >> =20 >> >> To >> >> "Busschbach, Peter B \(Peter\)" >> >, "Wojciech >> >> Dec \(wdec\)" , >> >> cc >> >> =20 >> >> Subject >> >> RE: [L2CP] Advantages of L2CP (was: Revised >=20 > WG=20 >=20 >>Charter Draft) >> >> >> >> >> >> =20 >> >> >> >> >> >> >> >> >> >> >> >> Peter >> >> Please see inline.. >> >> >> >> >-----Original Message----- >> >> >From: Busschbach, Peter B (Peter) >> >[mailto:busschbach@lucent.com] >> >> >Sent: Wednesday, April 05, 2006 10:51 AM >> >> >To: 'Wojciech Dec (wdec)'; l2cp@ietf.org >> >> >Subject: [L2CP] Advantages of L2CP (was: Revised WG >> >Charter Draft) >> >> > >> >> > >> >> >Hi Woj, >> >> > >> >> >To address the second half of our email exchange: >> >> > >> >> >I did notice the sentence that addressed Dave's concern. >> >> >However, my point was that the charter claims that L2CP = will >> >> >have a specific benefit ("avoiding complex >=20 > cross-organization >=20 >> >> >interactions"), while it is far from clear that in this >> >> >respect L2CP is any better than other solutions. >> >> >> >> [Sanjay] All that the charter is saying is that L2C work >> >will undertake >> >> use-cases that aim to simplify service management by >> >avoiding complex >> >> cross-organization interactions. It is a nobel goal that >> >L2C is striving >> >> to achieve.. What is wrong with that ? This is >> >irrespective of wether >> >> other solutions can provide this or not. >> >> So, as an example, charter for a new dynamic routing >> >protocol might say >> >> that it will strive to achieve fast network-wide >> >convergence (which is a >> >> clear benefit over static routing). But, obviously it is >> >ok for multiple >> >> dynamic routing protocols to work towards this goal and have >=20 > this >=20 >> >> explicitly stated in their charter. >> >> >> >> -Sanjay >> >> >> >> >> >> >I believe that the charter should avoid stating benefits >=20 > that >=20 >> >> >are debatable and therefore suggest that the text that I >> >> >quoted in my first email be deleted from the charter. >> >> > >> >> >Peter >> >> > >> >> >> -----Original Message----- >> >> >> From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] >> >> >> Sent: Wednesday, April 05, 2006 7:34 AM >> >> >> To: Busschbach, Peter B (Peter); l2cp@ietf.org >> >> >> Subject: RE: [L2CP] Re: Revised WG Charter Draft >> >> >> >> >> >> >> >> >> Hi Peter, >> >> >> >> >> >> To address 1) we have put in the following statement >> >in the charter >> >> >> which you may have not noticed. >> >> >> >> >> >> "The protocol design will not preclude other uses of >=20 > L2CP." >=20 >> >> >> >> >> >> WRT 2) we do not lay any claims to how different >> >operators structure >> >> >> their data bases, and some are probably better at doing = it >> >> >> than others. >> >> >> However it does seem to be a fairly common problem that >=20 > the >=20 >> >> >> info related >> >> >> to a single subscriber's network service needs to be >=20 > farmed >=20 >> >> >> out and fed >> >> >> into numerous custom built manager systems besides also >=20 > the >=20 >> >> >Radius DB. >> >> >> The idea is to allow a mechanism, through the use of = L2CP, >> >> >to have the >> >> >> Access node be provided with such information as and when >> >> >> needed by the >> >> >> NAS which in turn accesses a common repository like >> >a Radius DB. >> >> >> Dave's statement was, I believe, in relation to different >> >> >> subject; that >> >> >> of a wholesale-retail operation, where indeed the >> >> >relationship is more >> >> >> complex. However we do plan on addressing this as >> >evidenced by the >> >> >> statement in the charter: >> >> >> "L2CP will address security aspects of the control >=20 > protocol, >=20 >> >> >including >> >> >> the trust model between NAS nodes and access nodes." >> >> >> >> >> >> Regards, >> >> >> Woj. >> >> >> >> >> >> -----Original Message----- >> >> >> From: Busschbach, Peter B (Peter) >> >[mailto:busschbach@lucent.com] >> >> >> Sent: 04 April 2006 21:23 >> >> >> To: 'l2cp@ietf.org' >> >> >> Subject: [L2CP] Re: Revised WG Charter Draft >> >> >> >> >> >> I have two comments on the revised charter. >> >> >> >> >> >> 1) At the end of the BOF, Mark >> >Townsley limited >> >> the scope of the >> >> >> working group. Unfortunately, this is not captured very >> >> >clearly in the >> >> >> meeting minutes. The critical sentence in the >> >meeting minutes is >> >> "DSL >> >> >> but good engineers ...". I.e. the focus of the WG is >> >to solve a >> >> >> particular issue in DSL access networks, but as good >> >> >> engineers we should >> >> >> not preclude the use of the protocol for other >=20 > applications. >=20 >> >> >> >> >> >> I don't see the limited scope reflected in the new >=20 > charter. >=20 >> >> >> >> >> >> 2) Under "Line Configuration". the >> >charter says: >> >> >> >> >> >> > L2CP is intended to simplify the OSS >> >infrastructure for service >> >> >> > management, allowing subscriber-related service data to >=20 > be >=20 >> >> >> maintained >> >> >> > in fewer repositories (e.g. RADIUS server back-end >> >database) >> >> while >> >> >> > avoiding complex cross-organization interactions. >> >> >> >> >> >> I don't understand how L2CP leads to fewer Radius server >> >> >back end data >> >> >> bases. I also don't understand how L2CP avoids >> >cross-organizational >> >> >> interactions. There seems to be an assumption that it is >=20 > ok >=20 >> >> >> for L2CP to >> >> >> cross organizational boundaries but not for other >> >protocols. I don't >> >> >> think that is correct. At the BOF, Dave Allan pointed out >=20 >=20 >> >> >> that this is >> >> >> one of the more difficult problems to solve. Therefore, I >> >> >believe that >> >> >> this text should be removed from the charter. >> >> >> >> >> >> Peter --=20 Jakob Heitz. _______________________________________________ L2cp mailing list L2cp@ietf.org https://www1.ietf.org/mailman/listinfo/l2cp _______________________________________________ L2cp mailing list L2cp@ietf.org https://www1.ietf.org/mailman/listinfo/l2cp From l2cp-bounces@ietf.org Wed May 31 15:18:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlWCo-0001S5-PM; Wed, 31 May 2006 15:18:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlWCn-0001Rj-JG for l2cp@ietf.org; Wed, 31 May 2006 15:18:09 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlWCm-0005Mi-IF for l2cp@ietf.org; Wed, 31 May 2006 15:18:09 -0400 Received: from unknown (HELO up-smtp.jnpr.net) ([172.26.192.132]) by borg.juniper.net with ESMTP; 31 May 2006 12:18:07 -0700 X-IronPort-AV: i="4.05,194,1146466800"; d="scan'208"; a="555095134:sNHT66436312" Received: from emailemea5.jnpr.net ([172.26.192.134]) by up-smtp.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 31 May 2006 20:18:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: [L2CP] RE: Wadhwa new draft 01- Encapsulation Date: Wed, 31 May 2006 20:17:36 +0100 Message-ID: In-Reply-To: <6439282641581441A36F7F6F83ED2ED287CEE2@S4DE8PSAAFQ.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [L2CP] RE: Wadhwa new draft 01- Encapsulation Thread-Index: AcaEg7ahhrEXyVNtTtqrr2D6L47fjQAXT3nA From: "Derek Harkness" To: "Haag, T" , X-OriginalArrivalTime: 31 May 2006 19:18:06.0290 (UTC) FILETIME=[F1EE2B20:01C684E6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8279e2b0006e70acac79ca9454596384 Cc: l2cp@ietf.org X-BeenThere: l2cp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Layer 2 Control Protocol Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: l2cp-bounces@ietf.org Hi, I have been thinking about this and I think regarding L2 encapsulation = and ANCP we are chasing a ghost here. Let's think about what the access node is the exclusive source of = information - and other cases where it could report but is by no means = the exclusive source of information.=20 Note also that if I understand correctly, a motivator for the = encapsulation discussion in TR 101 related to the PPPoA/PPPoE IWF in the = access node - where a BRAS/BSR/NAS sees what looks like PPPoE but is on = the local loop PPPoA and therefore needs different shaping. That's not = an ANCP issue. I shall term the thing doing the shaping and taking account of the = overhead "the shaping point" from now on. So, what the Access Node is the exclusive source of info for ? 1. The raw DSL BW 2. The local loop encapsulation (ATM, Ethernet)which is encoded in the = DSL type. 3. Any additional overhead factors on that local loop which is I think = where I came in with other overheads due to encoding, error checking and = other local loop specific factors.=20 Other information which may be used for shaping by the shaping point is = the encapsulation (PPPoE, IPOE) - which it knows as its processing the = protocol in some way, plus possible additional overheads added by any = intervening access network - where it must receive that info from = somewhere, but this overhead is not access node specific, and therefore = is out of scope for ANCP.=20 I.e. if I decide to build my access network using backhaul via stacked = VLANs over stacked MPLS labels over GRE tunnels over IPSec tunnels etc - = I exaggerate but bear with me - then that info is can be added in the = local offset factors as mentioned by Jakob earlier. This I'll call (4). = This information is not known to the Access Node where it is added by a = network in between. In the special case of PPPoA IWF - where the IWF is probably also the = access node - there is already a defined source for such information. Where the shaping point processes one protocol for the line then it has = all info it requires ( BW(1), encapsulation - from processing - , local = loop overhead (2&3)and an offset factor for a network in between(4) ). Where the same shaping point may be terminating/processing multiple = encaps on the same line - say PPPoE and IPoE - then it has sufficient = information to shape to the line speed accordingly. It has to take = account of these in its QoS handling. I don't want to broaden into an architectural discussion, but where = there might be multiple shaping points the issue is not one of the AN = informing the shaping points as to the encapsulation(s) involved, but = how those multiple shaping points know what the others are doing, which = is not in the scope of the encapsulation discussion.=20 Informing multiple adjacencies via ANCP is I beleive covered by the = charter but independent of this dicussion. Therefore I would, in my longwinded way, agree with Jakob and allay = Thomas's concern, the only potentially missing piece of the puzzle is = (3). Again, as Jakob says if this differs for different protocols this might = require knowledge of IPoE vs PPPoE. But unless the AN is processing = these protocols I don't see why the overhead should be different - it = gets a packet, adds some encoding and sends it on the line. The case = where the AN does protocol interworking is already identified for the = PPPoA IWF. Otherwise it is similar to my hypothetical access network and = is adding some overhead per transported packet. Therefore the only question is how to reflect (3) - if and where any = additional overhead exists - in addition to the raw BW and local loop = encapsulation.=20 Make sense, anyone ? 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 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 -----Original Message----- From: Haag, T [mailto:Thomas.Haag@t-systems.com]=20 Sent: 31 May 2006 09:27 To: jheitz@redback.com Cc: l2cp@ietf.org Subject: AW: AW: [L2CP] RE: Wadhwa new draft 01- Encapsulation Jakob, May be I'm wrong but my understanding is as follows: If a customer connection is installed the BRAS has to be configured. = This include beside L2 circuit ID the encapsulation any way. So the BRAS = knew from the beginning which encapsulation type is used. So I think = having an encapsulation information is redundant because the shaper = implementation in the BRAS is independent on having the encapsulation = type or not. The shaper has to adapt/adjust to the given configuration = any way. Imagine the case to have more than one encapsulation type running over = the same L2 circuit (e.g. PPPoE & IPoE). Which encapsulation type is = reported? As far as I learned it is not possible to do this. Regards Thomas -----Urspr=FCngliche Nachricht----- Von: Jakob Heitz [mailto:jheitz@redback.com]=20 Gesendet: Mittwoch, 31. Mai 2006 00:53 An: Haag, Thomas; l2cp@ietf.org Betreff: Re: AW: [L2CP] RE: Wadhwa new draft 01- Encapsulation Haag, T wrote: > I share Derek's view. >=20 > I have some concerns that signalling of the encapsulation will solve = the problem at all because a real impact in shaping and corresponding = overhead is the IP packet length which is not fix. The shapers and rate-limiters know the length of packets. They can count the bytes in a packet and add a fixed overhead per packet. They can even account for ATM cell overhead, even when an ATM cell is only partially used. The only problem I see is to tell the shaper the properties of the line. That problem can be solved. Does this address your concerns? >=20 > Also to have different encapsulation types (like PPPoE and IPoE) in = one circuit (VLAN or PVC) will not be solved. If the per-packet overhead is the same for PPPoE and IPoE, then the problem is trivial. If not, then the problem is merely a little harder, but can still be solved. The only question I have is how do we find out what that overhead is. Why do you think the problem will not be solved? >=20 > Regards > Thomas >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: Derek Harkness [mailto:dharkness@juniper.net]=20 > Gesendet: Dienstag, 30. Mai 2006 10:11 > An: stefaan.de_cnodder@alcatel.be > Cc: l2cp@ietf.org > Betreff: RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation >=20 > I understand that if this is a fixed overhead it should be subtracted > from the BW before it is passed in ANCP. However I understood that = there > are packet length dependent overheads on the line encoding which = cannot > be handled in this way.=20 >=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 >=20 > -----Original Message----- > From: stefaan.de_cnodder@alcatel.be > [mailto:stefaan.de_cnodder@alcatel.be]=20 > Sent: 29 May 2006 14:10 > To: Derek Harkness > Cc: l2cp@ietf.org > Subject: Re: [L2CP] RE: Wadhwa new draft 01- Encapsulation >=20 >=20 > Hi Derek, >=20 > see below >=20 > Derek Harkness wrote: >=20 >=20 >>=20 >>We have seen this from deployments using VDSL2 DSLAMs. My >=20 > understanding=20 >=20 >>is that the overhead is due to the local loop framing which includes=20 >>FEC, trellis encoding and other factors. Possibly this can be derived=20 >>from the DSL type which we already have in the protocol - I am not=20 >>familiar enough with the details of all DSL encodings to be able to=20 >>judge that, maybe the access node experts could shed some light here ? >>=20 >=20 >=20 > These physical layer overhead cannot be derived from the DSL type=20 > because trellis encoding for instance can be switched off or on.=20 > However, this overhead of the physical layer is already substracted = from >=20 > the physical bit rate when computing the actual bit rate so I guess=20 > there are no issue. >=20 > regards, > Stefaan >=20 >=20 >=20 >=20 >>Cheers, >>=20 >> Derek. >>=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 >>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 > = ------------------------------------------------------------------------ >=20 >>*From:* Michel.Platnic@ecitele.com [mailto:Michel.Platnic@ecitele.com] >>*Sent:* 24 May 2006 11:46 >>*To:* Sanjay Wadhwa >>*Cc:* l2cp@ietf.org >>*Subject:* RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation >> >> >>Hi Sanjay and all, >>I support Sanjay's proposal to have this encapsulation transported by=20 >>ANCP, even if we may argue that >>we already have 2 protocols that may transport this information (DHCP=20 >>and PPPoE). >>About having a different TLV to transport the Encapsulation, it only=20 >>partially solves the problem of potentially mixing >>layer 1 and layer 2 information. Actually the DSL forum (TR-101) uses=20 >>same principle described in your document to transport this >>information, it is probably wise to follow the same mechanism.. >>Unless other people share this concern, I'll go with your proposal. >>Best Regards, >>Michel. >> >> >> >>*"Sanjay Wadhwa" * >> >>24/05/2006 00:01 >> >>=09 >>To >> >>cc >> l2cp@ietf.org >>Subject >> RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation + Remode Id >=20 > comments >=20 >> >>=09 >> >> >> >> >> >> >> >> >-----Original Message----- >> >From: stefaan.de_cnodder@alcatel.be >> >[mailto:stefaan.de_cnodder@alcatel.be] >> >Sent: Tuesday, May 23, 2006 1:07 PM >> >To: Sanjay Wadhwa >> >Cc: l2cp@ietf.org >> >Subject: Re: [L2CP] RE: Wadhwa new draft 01- Encapsulation + Remode >=20 > Id >=20 >> >comments >> > >> > >> > >> >Hi Sanjay, >> > >> >> >> >> - Why was the access loop encapsulation object included within >=20 > a >=20 >> >> message where all parameters transmitted are layer 1 oriented? >> >> There might be several encapsulations available per >> >physical link, a >> >> new message could maybe better serve the purpose of >> >> transmitting the encapsulation parameters. >> >> [[SW]] I have sympathy for your arguement as I had a similar >> >> concern, which is why L2 encaps has been specified as a >> >seprate and >> >> optional TLV (although same message). >> >> It is to an extent useful for the BNG to learn l2 encaps on >=20 > the >=20 >> >> local-loop as it can in some cases allow for more >> >accurate shaping >> >> of subscriber traffic. >> >> >> > >> >Why not specifying the bandwidth at L2? Then the BNG just takes this >> >bandwidth for shaping and it does not have to take care of what >> >encapsulation has been used. Why bottering the BNG with the >> >encap on the >> >DSL line. And what if later someone wants to do the same on non-DSL >> >access lines? Are we going to add encap types and updating the >> >BNG with >> >these new encap types to compute the correct shaping rate? I >> >believe it >> >would be better to specify the bandwidth at which the BNG has to >=20 > shape. >=20 >>[SW] Shaping on the BNG (based on counting bytes transmitted) needs to >>know the "byte adjustment" (under/over-head) due to difference in >=20 > encaps >=20 >>on the aggregation network and access loop. I suppose the access-node >>could indicate the absolute difference in terms of bytes between the >=20 > two >=20 >>encapsulations.. however, this might not be accurate as an aggregation >>switch upstream of the DSLAM could change the encaps (e.g. insert an >>outer VLAN tag). Ideally, the BNG needs to use the difference between >>it's encaps and the encaps on the local-loop. Also, the BNG needs to >>adjust for cell-tax if the local-loop is cell based. >> >>-Sanjay >> >> >> >regards, >> >Stefaan >> > >> > >> >> *Chapter 5.4.2* >> >> - Typo: >> >> Type (Access-Loop-Circuit-ID =3D 0x01) : defined in section >=20 > 5.4.1 >=20 >> >> Type (Access-Aggregation-Circuit-ID-Binary =3D 0x02): defined = in >> >> section 5.4.1. =20 >> >> Type (Access-Aggregation-Circuit-ID-ASCII =3D 0x03) : defined = in >> >> section 5.4.1. =20 >> >> These lines should be updated to comply to Chapter 5.4.1. >> >> >> >> [[SW]] Will fix. >> >> =20 >> >> Thanks >> >> -Sanjay >> >> >> >> Thanks and Best Regards, >> >> Michel. >> >> >> >> >> >> >> >> >> >> *"Sanjay Wadhwa" * >> >> >> >> 05/04/2006 19:22 >> >> >> >> =20 >> >> To >> >> "Busschbach, Peter B \(Peter\)" >> >, "Wojciech >> >> Dec \(wdec\)" , >> >> cc >> >> =20 >> >> Subject >> >> RE: [L2CP] Advantages of L2CP (was: Revised >=20 > WG=20 >=20 >>Charter Draft) >> >> >> >> >> >> =20 >> >> >> >> >> >> >> >> >> >> >> >> Peter >> >> Please see inline.. >> >> >> >> >-----Original Message----- >> >> >From: Busschbach, Peter B (Peter) >> >[mailto:busschbach@lucent.com] >> >> >Sent: Wednesday, April 05, 2006 10:51 AM >> >> >To: 'Wojciech Dec (wdec)'; l2cp@ietf.org >> >> >Subject: [L2CP] Advantages of L2CP (was: Revised WG >> >Charter Draft) >> >> > >> >> > >> >> >Hi Woj, >> >> > >> >> >To address the second half of our email exchange: >> >> > >> >> >I did notice the sentence that addressed Dave's concern. >> >> >However, my point was that the charter claims that L2CP will >> >> >have a specific benefit ("avoiding complex >=20 > cross-organization >=20 >> >> >interactions"), while it is far from clear that in this >> >> >respect L2CP is any better than other solutions. >> >> >> >> [Sanjay] All that the charter is saying is that L2C work >> >will undertake >> >> use-cases that aim to simplify service management by >> >avoiding complex >> >> cross-organization interactions. It is a nobel goal that >> >L2C is striving >> >> to achieve.. What is wrong with that ? This is >> >irrespective of wether >> >> other solutions can provide this or not. >> >> So, as an example, charter for a new dynamic routing >> >protocol might say >> >> that it will strive to achieve fast network-wide >> >convergence (which is a >> >> clear benefit over static routing). But, obviously it is >> >ok for multiple >> >> dynamic routing protocols to work towards this goal and have >=20 > this >=20 >> >> explicitly stated in their charter. >> >> >> >> -Sanjay >> >> >> >> >> >> >I believe that the charter should avoid stating benefits >=20 > that >=20 >> >> >are debatable and therefore suggest that the text that I >> >> >quoted in my first email be deleted from the charter. >> >> > >> >> >Peter >> >> > >> >> >> -----Original Message----- >> >> >> From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] >> >> >> Sent: Wednesday, April 05, 2006 7:34 AM >> >> >> To: Busschbach, Peter B (Peter); l2cp@ietf.org >> >> >> Subject: RE: [L2CP] Re: Revised WG Charter Draft >> >> >> >> >> >> >> >> >> Hi Peter, >> >> >> >> >> >> To address 1) we have put in the following statement >> >in the charter >> >> >> which you may have not noticed. >> >> >> >> >> >> "The protocol design will not preclude other uses of >=20 > L2CP." >=20 >> >> >> >> >> >> WRT 2) we do not lay any claims to how different >> >operators structure >> >> >> their data bases, and some are probably better at doing it >> >> >> than others. >> >> >> However it does seem to be a fairly common problem that >=20 > the >=20 >> >> >> info related >> >> >> to a single subscriber's network service needs to be >=20 > farmed >=20 >> >> >> out and fed >> >> >> into numerous custom built manager systems besides also >=20 > the >=20 >> >> >Radius DB. >> >> >> The idea is to allow a mechanism, through the use of L2CP, >> >> >to have the >> >> >> Access node be provided with such information as and when >> >> >> needed by the >> >> >> NAS which in turn accesses a common repository like >> >a Radius DB. >> >> >> Dave's statement was, I believe, in relation to different >> >> >> subject; that >> >> >> of a wholesale-retail operation, where indeed the >> >> >relationship is more >> >> >> complex. However we do plan on addressing this as >> >evidenced by the >> >> >> statement in the charter: >> >> >> "L2CP will address security aspects of the control >=20 > protocol, >=20 >> >> >including >> >> >> the trust model between NAS nodes and access nodes." >> >> >> >> >> >> Regards, >> >> >> Woj. >> >> >> >> >> >> -----Original Message----- >> >> >> From: Busschbach, Peter B (Peter) >> >[mailto:busschbach@lucent.com] >> >> >> Sent: 04 April 2006 21:23 >> >> >> To: 'l2cp@ietf.org' >> >> >> Subject: [L2CP] Re: Revised WG Charter Draft >> >> >> >> >> >> I have two comments on the revised charter. >> >> >> >> >> >> 1) At the end of the BOF, Mark >> >Townsley limited >> >> the scope of the >> >> >> working group. Unfortunately, this is not captured very >> >> >clearly in the >> >> >> meeting minutes. The critical sentence in the >> >meeting minutes is >> >> "DSL >> >> >> but good engineers ...". I.e. the focus of the WG is >> >to solve a >> >> >> particular issue in DSL access networks, but as good >> >> >> engineers we should >> >> >> not preclude the use of the protocol for other >=20 > applications. >=20 >> >> >> >> >> >> I don't see the limited scope reflected in the new >=20 > charter. >=20 >> >> >> >> >> >> 2) Under "Line Configuration". the >> >charter says: >> >> >> >> >> >> > L2CP is intended to simplify the OSS >> >infrastructure for service >> >> >> > management, allowing subscriber-related service data to >=20 > be >=20 >> >> >> maintained >> >> >> > in fewer repositories (e.g. RADIUS server back-end >> >database) >> >> while >> >> >> > avoiding complex cross-organization interactions. >> >> >> >> >> >> I don't understand how L2CP leads to fewer Radius server >> >> >back end data >> >> >> bases. I also don't understand how L2CP avoids >> >cross-organizational >> >> >> interactions. There seems to be an assumption that it is >=20 > ok >=20 >> >> >> for L2CP to >> >> >> cross organizational boundaries but not for other >> >protocols. I don't >> >> >> think that is correct. At the BOF, Dave Allan pointed out >=20 >=20 >> >> >> that this is >> >> >> one of the more difficult problems to solve. Therefore, I >> >> >believe that >> >> >> this text should be removed from the charter. >> >> >> >> >> >> Peter --=20 Jakob Heitz. _______________________________________________ L2cp mailing list L2cp@ietf.org https://www1.ietf.org/mailman/listinfo/l2cp _______________________________________________ L2cp mailing list L2cp@ietf.org https://www1.ietf.org/mailman/listinfo/l2cp _______________________________________________ L2cp mailing list L2cp@ietf.org https://www1.ietf.org/mailman/listinfo/l2cp