Subject: [L2CP] questions on procotol spec

From: [email-masked]
Date: Mon, 13 Mar 2006 19:21:42 +0100

Hi,

I have some questions/comments on 
draft-wadhwa-gsmp-l2control-configuration-00

1) section 4.2.1 mentions the case where the line retrains in which case 
only a Port UP is sent with updated line parameters. If a DSL line goes 
out of sync and then comes in sync again, I would expect first a Port 
Down followed by a Port UP when the line is in Sync again. Is it the 
intention that the Port Down is not sent when the line goes out of sync 
because this is wat the draft seems to suggest? In case the line changes 
the bandwidth without going out of sync, then scenario 2 in figure 2 
looks correct.

2) second paragraph of 5.1 says that the BRAS starts with the adjacency 
protocol after the TCP session is up. The last sentence of the 4th 
paragraph of section 5.2 says that both sides tries to re-establish the 
adjacency. Maybe it should be made more clear what the role is of DSLAM 
and BRAS. I would expect that both sides can start the adjacency so I 
believe it would be better to rephrase the sentence in section 5.1

3) section 5.3 introduces the tech type "DSL" in the capability 
negotiation. Is it possible for the access node to advertise more than 1 
tech type. What if the access node supports more than DSL only?

4) What is the value of "Block Length" in section 5.4.1 in case the 
lenght is larger than 255. Is it set to 255 although the real length is 
longer (as given by "Extension blcok length"). Is "block length" always 
be ignored, even in case it is smaller than 255?

5) Access-Aggregation-Circuit-ID-Binary is 8 bytes. How are the VLANs 
and VPI/VCI encoded? The draft says 2 32 bit integers. I would expect in 
case of VLANs, the first 20 bits are zero, then the next 12 bits are the 
inner VLAN, then again 20 bits zero, and the next 12 bits the outer 
VLAN. Is this correct? Can this be made more explicit in the draft?

6) Section 5.4.2 says that for line config, TLVs not understood by the 
BRAS should be ignored. I believe you mean the DSLAM instead of BRAS? 
How is the BRAS in this case suppose to know whether the config was 
successful or not? Should the DSLAM respond with a failure instead if 
there is an unknown sub-TLV? The same question on OAM (section 5.4.3).

Thanks,

Stefaan

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

---

From: "Sanjay Wadhwa" <[email-masked]>
Date: Tue, 21 Mar 2006 13:42:35 -0500

Hi Steffan
  Somehow this went un-noticed. Anyway, please see inline.   

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]]
>Sent: Monday, March 13, 2006 1:22 PM
>To: [email-masked]
>Subject: [L2CP] questions on procotol spec
>
>
>
>Hi,
>

If the line changes to a b/w between min and max window and doesn't go
out of sync, only a PORT_UP should be generated. If a line goes  out of
sync or in case of loss of signal, PORT_DOWN should be generated.
Section 4.1 doesn't say anything to the contrary.
4.2.2 is actually referring to scenario 2.  

>believe it would be better to rephrase the sentence in section 5.1

There is no restriction on which side initiates adjacency messages. Both
sides can send SYN (transition to SYNSENT state.. on reception of SYNACK
transition to ESTAB state). Most likely scenario is BRAS will end up
sending the SYN first (since it is listening and accepting TCP
connection). 
The intention of text in section 5.1 was not to imply ordering on
adjacency initiation. I can clarify if you think it helps.

>tech type. What if the access node supports more than DSL only?

As currently specified, an adjacency message carries capabilities for a
single "technology type". I believe today this is sufficient. Even with
current specification, single access node supporting multiple
technologies could be accomodated via partitioning.
If needed , we can in the future allow for capability TLVs for multiple
tech types in the same message. We will need to describe capability
mis-match behaviour accordingly then.

>be ignored, even in case it is smaller than 255?

I expect "extension block length" to be used always.   

>VLAN. Is this correct? Can this be made more explicit in the draft?

True, in case of VLANs, it is the two VLAN-IDs (12 bytes each in the two
32 bit integers). I can clarify.

>BRAS should be ignored. I believe you mean the DSLAM instead of BRAS? 

It is a typo. Will fix. 

>successful or not? 

Optionally, the BRAS can insert "AckAll" in result field to solicit a
response. I was loath to using this generally for all line configuration
cases, since the currently discussed line config use-case more or less
involves just transporting from BNG to AN, some information that is
pretty much opaque to the BNG and meaningful to the DSLAM. The transport
in this case is guaranteed to be reliable..       
We can talk more on this..

>Should the DSLAM respond with a failure instead if 

-Sanjay