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

From: "Haag, T" <[email-masked]>
Date: Wed, 24 May 2006 13:46:37 +0200

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üngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] 
Gesendet: Mittwoch, 24. Mai 2006 11:46
An: Sanjay Wadhwa
Cc: [email-masked]
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" <[email-masked]> 

24/05/2006 00:01 

To

<[email-masked]> 

cc

[email-masked] 

Subject

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

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]]
>Sent: Tuesday, May 23, 2006 1:07 PM
>To: Sanjay Wadhwa
>Cc: [email-masked]
>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" <[email-masked]>*
>> 
>>     05/04/2006 19:22
>> 
>>                      
>>     To
>>                      "Busschbach, Peter B \(Peter\)" 
><[email-masked]>, "Wojciech
>>     Dec \(wdec\)" <[email-masked]>, <[email-masked]>
>>     cc
>>                      
>>     Subject
>>                      RE: [L2CP] Advantages of L2CP (was: Revised WG Charter Draft)
>> 
>> 
>>                      
>> 
>> 
>> 
>> 
>> 
>>     Peter
>>      Please see inline..
>> 
>>      >-----Original Message-----
>>      >From: Busschbach, Peter B (Peter) 
>[mailto:[email-masked]]
>>      >Sent: Wednesday, April 05, 2006 10:51 AM
>>      >To: 'Wojciech Dec (wdec)'; [email-masked]
>>      >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:[email-masked]]
>>      >> Sent: Wednesday, April 05, 2006 7:34 AM
>>      >> To: Busschbach, Peter B (Peter); [email-masked]
>>      >> 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:[email-masked]]
>>      >> Sent: 04 April 2006 21:23
>>      >> To: [email-masked]'
>>      >> 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
>>      >> [email-masked]
>>      >> https://www1.ietf.org/mailman/listinfo/l2cp
>>      >>
>>      >
>>      >_______________________________________________
>>      >L2cp mailing list
>>      >[email-masked]
>>      >https://www1.ietf.org/mailman/listinfo/l2cp
>>      >
>> 
>>     _______________________________________________
>>     L2cp mailing list
>>     [email-masked]
>>     https://www1.ietf.org/mailman/listinfo/l2cp
>> 
>> 
>> 
>---------------------------------------------------------------
>---------
>> 
>> _______________________________________________
>> L2cp mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/l2cp
>

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

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

---

From: "Sanjay Wadhwa" <[email-masked]>
Date: Thu, 25 May 2006 08:53:39 -0400

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. 
 
-Sanjay
 
 -----Original Message-----
From: Haag, T [mailto:[email-masked]]
Sent: Wednesday, May 24, 2006 7:47 AM
To: [email-masked]; Sanjay Wadhwa
Cc: [email-masked]
Subject: AW: [L2CP] RE: Wadhwa new draft 01- Encapsulation 

Regards

Thomas 

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] 
Gesendet: Mittwoch, 24. Mai 2006 11:46
An: Sanjay Wadhwa
Cc: [email-masked]
Betreff: RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation 

Hi Sanjay and all, 

24/05/2006 00:01 

To

cc

[email-masked] 

Subject

 

-Sanjay

---

From: [email-masked]
Date: Mon, 29 May 2006 10:49:53 +0300

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 
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.

25/05/2006 15:53

To
"Haag, T" <[email-masked]>, <[email-masked]>
cc
<[email-masked]>
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 appropriately report it for both ACIs and adjust 
the shaper on the BNG. 
 
-Sanjay
 
 -----Original Message-----
From: Haag, T [mailto:[email-masked]]
Sent: Wednesday, May 24, 2006 7:47 AM
To: [email-masked]; Sanjay Wadhwa
Cc: [email-masked]
Subject: AW: [L2CP] RE: Wadhwa new draft 01- Encapsulation 

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üngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] 
Gesendet: Mittwoch, 24. Mai 2006 11:46
An: Sanjay Wadhwa
Cc: [email-masked]
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. 

To

-Sanjay

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 29 May 2006 14:10:49 -0700

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)?

[email-masked] wrote:
> Should we send Layer 1 information in both messages, in one of them, in 
> a different message?
> 
> Regards,
> Michel.
> 
> 
> 
> then we should be able to appropriately report it for both ACIs and 
> adjust the shaper on the BNG.
>  
> -Sanjay
>  
>  -----Original Message-----*
> From:* Haag, T [mailto:[email-masked]]*
> Sent:* Wednesday, May 24, 2006 7:47 AM*
> To:* [email-masked]; Sanjay Wadhwa*
> Cc:* [email-masked]*
> Subject:* AW: [L2CP] RE: Wadhwa new draft 01- Encapsulation
> 
> 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?
> 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üngliche Nachricht-----*
> Von:* [email-masked] [mailto:[email-masked]] *
> Gesendet:* Mittwoch, 24. Mai 2006 11:46*
> An:* Sanjay Wadhwa*
> Cc:* [email-masked]*
> Betreff:* RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation
>  
> 
> Hi Sanjay and all,
> layer 1 and layer 2 information. Actually the DSL forum (TR-101) uses 
> same principle described in your document to transport this

-- 
Jakob Heitz.

---

From: [email-masked]
Date: Tue, 30 May 2006 09:49:02 +0200

> access loop) and a new identifier for it?

Since the Access-Loop-Circuit-ID may contain the vlan or vpi.vci, 2 
virtual circuits on the same DSL line may have different 
Access-Loop-Circuit-IDs. It looks to me that we already have a virtual 
circuit id but that the real loop id is missing.....

If the string in the Access-Loop-Circuit-ID MUST follow the format as 
described in the draft with slot/port:vpi.vci then it already contains 
both the access loop and virtual circuit and nothing new is needed. 
However the draft says that this is just a "typical format".

regards,
Stefaan

>> If we have on the same DSL port 2 encapsulations 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.
>>
>>
>>
>>   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.
>>  
>> -Sanjay
>>  
>> 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.
>>  
>>  >>     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.
>>  >>
>>  >>
>>  >>
>>  >>