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

["Derek Harkness" <[e-mail]>]

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. 

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. 

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. 

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. 

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. 

	Make sense, anyone ?

		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: Haag, T [mailto:[e-mail]] 
Sent: 31 May 2006 09:27
To: [e-mail]
Cc: [e-mail]
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üngliche Nachricht-----
Von: Jakob Heitz [mailto:[e-mail]] 
Gesendet: Mittwoch, 31. Mai 2006 00:53
An: Haag, Thomas; [e-mail]
Betreff: Re: AW: [L2CP] RE: Wadhwa new draft 01- Encapsulation

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

_______________________________________________
L2cp mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/l2cp

_______________________________________________
L2cp mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/l2cp