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

From: [email-masked]
Date: Mon, 22 May 2006 15:56:57 +0300

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

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.

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

---

From: "Sanjay Wadhwa" <[email-masked]>
Date: Tue, 23 May 2006 10:11:40 -0400

Hi Michel
  Please see inline.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, May 22, 2006 8:57 AM
To: Sanjay Wadhwa
Cc: [email-masked]
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: 

[[SW]] Will fix.
 
Thanks
-Sanjay 

Thanks and Best Regards, 
Michel. 

05/04/2006 19:22 

To

cc

Subject

Peter
 Please see inline..

-Sanjay

>> 1)                 At the end of the BOF, Mark Townsley limited the
scope of the

---

From: [email-masked]
Date: Tue, 23 May 2006 19:07:13 +0200

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

regards,
Stefaan

>     *Chapter 5.4.2*
>     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.  
>     *"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
>      >> 1)                 At the end of the BOF, Mark Townsley limited
>     the scope of the
> ------------------------------------------------------------------------
>

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 23 May 2006 10:22:31 -0700

> would be better to specify the bandwidth at which the BNG has to shape.

Bandwidth is bits per second.
This is not enough for shaping.
The shaper also needs to know when to subtract
a packet header overhead or a cell header overhead.
It needs intimate knowledge about how to calculate
the overhead.

Basically, the bandwidth will be smaller for short
packets than long packets.

-- 
Jakob Heitz.

---

From: "Sanjay Wadhwa" <[email-masked]>
Date: Tue, 23 May 2006 17:01:07 -0400

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

[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

>>      >> meeting minutes. The critical sentence in the 
>meeting minutes is
>>     "DSL
>>      >> > in fewer repositories (e.g. RADIUS server back-end 
>database)
>>     while

---

From: [email-masked]
Date: Wed, 24 May 2006 12:46:01 +0300

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.

24/05/2006 00:01

To
<[email-masked]>
cc
[email-masked]
Subject
RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation + Remode Id comments

-Sanjay

---

From: [email-masked]
Date: Wed, 24 May 2006 12:50:26 +0300

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.

23/05/2006 17:11

To
<[email-masked]>
cc
[email-masked]
Subject
[L2CP] RE: Wadhwa new draft 01- Encapsulation + Remode Id comments

Hi Michel
  Please see inline.
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, May 22, 2006 8:57 AM
To: Sanjay Wadhwa
Cc: [email-masked]
Subject: Wadhwa new draft 01- Encapsulation + Remode Id comments

Hi Sanjay and all, 

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.

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

[[SW]] Will fix.
 
Thanks
-Sanjay 

Thanks and Best Regards, 
Michel. 

To

Subject

Peter
 Please see inline..

-Sanjay

scope of the

---

From: "Derek Harkness" <[email-masked]>
Date: Wed, 24 May 2006 11:46:45 +0100

It would also seem to me desireable to keep the approach consistent with
other approaches such as the PPPoE IA/DHCP stuff from DSLF TR-101 as
then the internal handling can be easier as it has the encapsulation
information from local config, and/or PPPoE IA/DHCP Options and/or L2C,
depending on the application and customer preference. 
 
Then the BNG knows the local loop type (ATM or Eth) from the DSL type
and knows the local loop encapsulation - and its local encapsulation
where this differs (e.g. additional VLAN tags) - and should be able to
set the shaping accordingly.
 
The only potential fly in the ointment is that there is on some DSL
types a kind of "L1andabit" framing overhead - similar to say inter
packet gap on ethernet, or framing bits round HDLC/FR frames for us more
venerable members of the audience - which is not described by either the
BW or the L2 encapsulation. 
 
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 ?
 
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: [email-masked]
+=============================+ 

________________________________

From: [email-masked] [mailto:[email-masked]] 
Sent: 24 May 2006 11:46
To: Sanjay Wadhwa
Cc: [email-masked]
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. 

24/05/2006 00:01 

To

-Sanjay

---

From: [email-masked]
Date: Mon, 29 May 2006 14:10:01 +0200

Hi Derek,

see below

> 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

> Email: [email-masked] <mailto:[email-masked]>
> *From:* [email-masked] [mailto:[email-masked]]
> *Sent:* 24 May 2006 11:46
> *To:* Sanjay Wadhwa
> *Cc:* [email-masked]
> *Subject:* RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation
> 
> 
> Hi Sanjay and all,

---

From: "Derek Harkness" <[email-masked]>
Date: Tue, 30 May 2006 09:10:59 +0100

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.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: 29 May 2006 14:10
To: Derek Harkness
Cc: [email-masked]
Subject: Re: [L2CP] RE: Wadhwa new draft 01- Encapsulation

Hi Derek,

see below

regards,
Stefaan

>  >>                      RE: [L2CP] Advantages of L2CP (was: Revised
WG 
> Charter Draft)

---

From: [email-masked]
Date: Tue, 30 May 2006 16:00:30 +0200

Hi Derek,

Indeed, although some parts of the overhead are already substracted from 
the data rate by the DSLAM, it seems there is more overhead (frame 
length depending) on the physical layer that is not yet substracted.

regards,
Stefaan

Derek Harkness wrote:

>>We have seen this from deployments using VDSL2 DSLAMs. My
> 
> understanding 
> 
>>	RE: [L2CP] RE: Wadhwa new draft 01- Encapsulation + Remode Id
> 
> comments
> 
>>
>>	
>>
>>
>>
>>
>>
>>
>>
>> >Subject: Re: [L2CP] RE: Wadhwa new draft 01- Encapsulation + Remode
> 
> Id
> 
>> >comments
>> >
>> >
>> >
>> >Hi Sanjay,
>> >
>> >>
>> >>     - Why was the access loop encapsulation object included within
> 
> a
> 
>> >>     It is to an extent useful for the BNG to learn l2 encaps on
> 
> the
> 
>> >would be better to specify the bandwidth at which the BNG has to
> 
> shape.
> 
>>know the "byte adjustment" (under/over-head) due to difference in
> 
> encaps
> 
>>could indicate the absolute difference in terms of bytes between the
> 
> two
> 
>> >>     Type (Access-Loop-Circuit-ID = 0x01) : defined in section
> 
> 5.4.1
> 
>> >>      >have a specific benefit ("avoiding complex
> 
> cross-organization
> 
>> >>     dynamic routing protocols to work towards this goal and have
> 
> this
> 
>> >>      >I believe that the charter should avoid stating benefits
> 
> that
> 
>> >>      >> "The protocol design will not preclude other uses of
> 
> L2CP."
> 
>> >>      >>
>> >>      >> 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.
>> >>      >> "L2CP will address security aspects of the control
> 
> protocol,
> 
>> >>      >including
>> >>      >> not preclude the use of the protocol for other
> 
> applications.
> 
>> >>      >>
>> >>      >> I don't see the limited scope reflected in the new
> 
> charter.
> 
>> >>      >>
>> >>      >> > management, allowing subscriber-related service data to
> 
> be
> 
>> >>      >> maintained
>> >>      >> interactions. There seems to be an assumption that it is
> 
> ok
> 
>> >>      >> for L2CP to