Re: AW: [L2CP] RE: Wadhwa new draft 01- Encapsulation

[Jakob Heitz <[e-mail]>]

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:[e-mail]] 
> Gesendet: Dienstag, 30. Mai 2006 10:11
> An: [e-mail]
> Cc: [e-mail]
> 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: [phone]
> Mobile: [phone]
> Email: [e-mail]
> +=============================+ 
> 
> 
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] 
> Sent: 29 May 2006 14:10
> To: Derek Harkness
> Cc: [e-mail]
> 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: [phone]
>>Mobile: [phone]
>>Email: [e-mail] <mailto:[e-mail]>
>>+=============================+
>> 
>>
>>
> 
> ------------------------------------------------------------------------
> 
>>*From:* [e-mail] [mailto:[e-mail]]
>>*Sent:* 24 May 2006 11:46
>>*To:* Sanjay Wadhwa
>>*Cc:* [e-mail]
>>*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" <[e-mail]>*
>>
>>24/05/2006 00:01
>>
>>	
>>To
>>	<[e-mail]>
>>cc
>>	[e-mail]
>>Subject
>>	RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation + Remode Id
> 
> comments
> 
>>
>>	
>>
>>
>>
>>
>>
>>
>>
>> >-----Original Message-----
>> >From: [e-mail]
>> >[mailto:[e-mail]]
>> >Sent: Tuesday, May 23, 2006 1:07 PM
>> >To: Sanjay Wadhwa
>> >Cc: [e-mail]
>> >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" <[e-mail]>*
>> >>
>> >>     05/04/2006 19:22
>> >>
>> >>                      
>> >>     To
>> >>                      "Busschbach, Peter B \(Peter\)"
>> ><[e-mail]>, "Wojciech
>> >>     Dec \(wdec\)" <[e-mail]>, <[e-mail]>
>> >>     cc
>> >>                      
>> >>     Subject
>> >>                      RE: [L2CP] Advantages of L2CP (was: Revised
> 
> WG 
> 
>>Charter Draft)
>> >>
>> >>
>> >>                      
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>     Peter
>> >>      Please see inline..
>> >>
>> >>      >-----Original Message-----
>> >>      >From: Busschbach, Peter B (Peter)
>> >[mailto:[e-mail]]
>> >>      >Sent: Wednesday, April 05, 2006 10:51 AM
>> >>      >To: 'Wojciech Dec (wdec)'; [e-mail]
>> >>      >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:[e-mail]]
>> >>      >> Sent: Wednesday, April 05, 2006 7:34 AM
>> >>      >> To: Busschbach, Peter B (Peter); [e-mail]
>> >>      >> 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:[e-mail]]
>> >>      >> Sent: 04 April 2006 21:23
>> >>      >> To: '[e-mail]'
>> >>      >> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/l2cp