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

[[e-mail]]

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" <[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 
>> 
>> 
>> 
>> _______________________________________________
>> 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

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