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

[[e-mail]]

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

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

> 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)?
> 
> [e-mail] wrote:
> 
>>
>> 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.
>>
>>
>>
>> *"Sanjay Wadhwa" <[e-mail]>*
>>
>> 25/05/2006 15:53
>>
>>     
>> To
>>     "Haag, T" <[e-mail]>, <[e-mail]>
>> cc
>>     <[e-mail]>
>> 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:[e-mail]]*
>> Sent:* Wednesday, May 24, 2006 7:47 AM*
>> To:* [e-mail]; Sanjay Wadhwa*
>> Cc:* [e-mail]*
>> Subject:* AW: [L2CP] RE: Wadhwa new draft 01- Encapsulation
>>
>> 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:* [e-mail] [mailto:[e-mail]] *
>> Gesendet:* Mittwoch, 24. Mai 2006 11:46*
>> An:* Sanjay Wadhwa*
>> Cc:* [e-mail]*
>> 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" <[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
> 
> 

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