Re: [L2CP] RE: Wadhwa new draft 01- Remode Id comments
Michel.Platnic@ecitele.com Wed, 24 May 2006 09:50 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiq0k-0005HM-IG; Wed, 24 May 2006 05:50:38 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiq0j-0005HH-NJ for l2cp@ietf.org; Wed, 24 May 2006 05:50:37 -0400
Received: from ilsmtp01.ecitele.com ([147.234.1.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fiq0e-0005Rm-Ag for l2cp@ietf.org; Wed, 24 May 2006 05:50:37 -0400
In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2803B756C9@proton.jnpr.net>
To: Sanjay Wadhwa <swadhwa@juniper.net>
Subject: Re: [L2CP] RE: Wadhwa new draft 01- Remode Id comments
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.3 September 14, 2004
Message-ID: <OF6E12C759.FC731F2A-ONC2257178.0035BF51-C2257178.00361286@ecitele.com>
From: Michel.Platnic@ecitele.com
Date: Wed, 24 May 2006 12:50:26 +0300
X-MIMETrack: Serialize by Router on ILSMTP01/ECI Telecom(Release 6.5.3FP1 | December 22, 2004) at 05/24/2006 12:58:28, Serialize complete at 05/24/2006 12:58:28
X-Spam-Score: 0.2 (/)
X-Scan-Signature: c96e11e58076fc8e92061fb6cbdfae15
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 <l2cp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l2cp>, <mailto:l2cp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/l2cp>
List-Post: <mailto:l2cp@ietf.org>
List-Help: <mailto:l2cp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l2cp>, <mailto:l2cp-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0143741595=="
Errors-To: l2cp-bounces@ietf.org
Hi Sanjay, About your answer: [[SW]] The aggregation info is for the uplink on the DSLAM. It is optional and is preferrable to keep it seperate from ACI or any other local loop related info. I am fine with your that. Thanks, Michel. "Sanjay Wadhwa" <swadhwa@juniper.net> 23/05/2006 17:11 To <Michel.Platnic@ecitele.com> cc l2cp@ietf.org Subject [L2CP] RE: Wadhwa new draft 01- Encapsulation + Remode Id comments Hi Michel Please see inline. -----Original Message----- From: Michel.Platnic@ecitele.com [mailto:Michel.Platnic@ecitele.com] Sent: Monday, May 22, 2006 8:57 AM To: Sanjay Wadhwa Cc: l2cp@ietf.org Subject: Wadhwa new draft 01- Encapsulation + Remode Id comments Hi Sanjay and all, Please find some comments and questions regarding the new internet-draft: 'draft-wadhwa-gsmp-l2control-configuration-01': Among the different modifications that were brought to the document, allow me underline the following: Chapter 5.4.1 - A new subscriber identifier has been added: Type (Access-Loop-Remote-Id = 0x02) as a consequence Access-Aggregation-Circuit-ID-Binary has been moved from type 0x02 to 0x04 - A new type has been added: Type (Access Loop Encapsulation = 0x90) as a consequence DSL-type has been moved from type 0x90 to 0x91 Questions about these changes: - I quite support the Access-Loop-Remote-Id new object. Having this new circuit identifier, though, do we still need the Access-Aggregation-Circuit-ID-ASCII object? Could we merge Access-Loop-Circuit-ID and Access-Aggregation-Circuit-ID-ASCII into one object that we could call Port-ID or Circuit-ID? [[SW]] The aggregation info is for the uplink on the DSLAM. It is optional and is preferrable to keep it seperate from ACI or any other local loop related info. Same question might be relevant for Access-Loop-Circuit-ID and Access-Aggregation-Circuit-ID-Binary but this would require previous agreement - We should agree that the same line identifier may be used for access link and aggregation link... - 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. 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" <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 _______________________________________________ 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] Advantages of L2CP (was: Revised WG Charte… Busschbach, Peter B (Peter)
- RE: [L2CP] Advantages of L2CP (was: Revised WG Ch… Sanjay Wadhwa
- RE: [L2CP] Advantages of L2CP (was: Revised WG Ch… Busschbach, Peter B (Peter)
- [L2CP] Wadhwa new draft 01- Encapsulation + Remod… Michel.Platnic
- [L2CP] RE: Wadhwa new draft 01- Encapsulation + R… Sanjay Wadhwa
- Re: [L2CP] RE: Wadhwa new draft 01- Encapsulation… stefaan.de_cnodder
- Re: [L2CP] RE: Wadhwa new draft 01- Encapsulation… Jakob Heitz
- RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation… Sanjay Wadhwa
- RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation Michel.Platnic
- Re: [L2CP] RE: Wadhwa new draft 01- Remode Id com… Michel.Platnic
- RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation Derek Harkness
- Re: [L2CP] RE: Wadhwa new draft 01- Encapsulation stefaan.de_cnodder
- RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation Derek Harkness
- Re: [L2CP] RE: Wadhwa new draft 01- Encapsulation stefaan.de_cnodder