Re: AW: [L2CP] RE: Wadhwa new draft 01- Encapsulation
Jakob Heitz <jheitz@redback.com> Tue, 30 May 2006 22:52 UTC
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 <jheitz@redback.com>
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" <Thomas.Haag@t-systems.com>, 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 <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>
Errors-To: l2cp-bounces@ietf.org
Haag, T wrote: > 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. 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? > > 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? > > Regards > Thomas > > > -----Ursprüngliche 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. > > 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 <mailto: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" <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 = 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 -- Jakob Heitz. _______________________________________________ L2cp mailing list L2cp@ietf.org https://www1.ietf.org/mailman/listinfo/l2cp
- AW: [L2CP] RE: Wadhwa new draft 01- Encapsulation Haag, T
- 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- Encapsulation Jakob Heitz
- Re: [L2CP] RE: Wadhwa new draft 01- Encapsulation stefaan.de_cnodder
- AW: [L2CP] RE: Wadhwa new draft 01- Encapsulation Haag, T
- Re: AW: [L2CP] RE: Wadhwa new draft 01- Encapsula… Jakob Heitz