Subject: RE: AW: [ANCP] Layer 2 Parameters in the Protocol document

From: "Wojciech Dec \(wdec\)" <[email-masked]>
Date: Tue, 3 Oct 2006 10:01:57 +0200

Regarding referencing of rfc3292 or of expired drafts I would suggest
that the ANCP protocol draft actually carries the full text of what's
required rather than a reference.
 
Regards,
Woj.

________________________________

From: [email-masked] [mailto:[email-masked]] 
Sent: 28 September 2006 16:37
To: Sanjay Wadhwa
Cc: Haag, T; [email-masked]
Subject: RE: AW: [ANCP] Layer 2 Parameters in the Protocol document

Hi Sanjay, 

In case of multiple VC or VLAN for which we need to send the
encapsulation as part of the 
'discovered parameters', I agree with you that best method should be to
allow 
one message to transport several Access-Loop-Remote-IDs. 
I guess we should probably add one sentence in the draft to document
this case. 

By the way, the 'bulk transaction message' is defined in
draft-ietf-gsmp-v3-base-spec-06 
but not in RFC3292, do we want to have references to a draft that is
expired? 

About the other point: wether or not to have the vpi.vci parameters as
optional 
within the Access-Loop-Remote-ID, if we do decide to keep these
parameters 
for historical reasons, we should probably define a default value to be
used 
for dummy vpi.vci. 

Thanks and Regards, 
Michel. 

"Sanjay Wadhwa" <[email-masked]> 

27/09/2006 21:42 

To
<[email-masked]>, "Haag, T" <[email-masked]> 
cc
<[email-masked]> 
Subject
RE: AW: [ANCP] Layer 2 Parameters in the Protocol document

Hi Michel 
  One of the main requirements on the BNG is to be able to correlate L2C
messages pertaining to a given access loop with subscriber sessions over
that access-loop. This is done via matching ACIs received in L2C
messages with what is received in DHCP opt 82 or PPPoE IA tag.  Ideally
the BNG should not have to interpret these values and should be able to
to transparently do an exact match. Keeping the formats in L2C and
DHCP/PPPoE identical allows this. 
The IETF draft mentions the syntax that you refer below as "typical"
syntax. However, it clearly states that the format of the ACI should be
identical to what is inserted by the DSLAM (signalling relay) in
subscriber signalling messages (as defined in TR-101, cited as a
reference in the IETF draft). TR-101 specifies a default syntax for the
ACI which includes VPI/VCI. However, it allows the default syntax to be
overriden by "flexible" syntax, which I believe lets you specify just
the slot/port. 
The intent in the IETF draft it to only require that the ACI sent in L2C
and DHCP/PPP messages by the DSLAM should match (and the format should
be transparent to the BNG). 
  
To your other point about encaps for multiple VCs per access-loop, it
doesn't have to be a seperate message. It could be a single message
containing a set of {ACI, DSL line attributes}. Other then encaps, rest
of the attributes would be identical in each set. 
  
Regards 
-Sanjay 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, September 27, 2006 12:18 PM
To: Haag, T
Cc: [email-masked]
Subject: Re: AW: [ANCP] Layer 2 Parameters in the Protocol document

Hi Thomas and All, 

Layer 2 parameters transmitted within the Access-Loop-Circuit-ID are
indeed a MUST for several use cases, 
so, as explained in your email, this layer 2 information should not be
removed. 

The Access-Loop-Circuit-ID is defined within
'draft-wadhwa-gsmp-l2control-configuration-01.txt' as follows: 
"Access-Node-Identifier atm slot/port:vpi.vci"   (when ATM/DSL is used) 

 "Access-Node-Identifier eth slot/port[:vlan-id]" (when Ethernet/DSL is
used) 

This means that for ATM interfaces at UI, vpi.vci MUST always be
transmitted. 

This brings us to at least 3 scenarios for the topology discovery use
case (when ATM/DSL is used): 
1- no layer 2 information needed, only layer 1 information required to
be transmitted 
2- single VC and layer 2 encapsulation required to be transmitted 
3- multi-VC and layer 2 encapsulation required to be transmitted 

Comments: 
Scenario1: vci.vpi is actually not required to be transmitted within
Access-Loop-Circuit-ID 
Scenario2: vci.vpi needed 
Scenario3: if encapsulation is needed for each (n) vci.vpi, it means
that n topology discovery messages must be transmitted. 

Proposal: 
If we replace  "Access-Node-Identifier atm slot/port:vpi.vci"   (when
ATM/DSL is used) 
by  "Access-Node-Identifier atm slot/port:[vpi.vci]"   (when ATM/DSL is
used) 
then vpi.vci becomes optional and we are fine with case 1. 

Question: 
Are we fine with the fact that in case of multiple VC (multiple VLAN as
well) we must transmit multiple messages? 

Regards, 
Michel. 

"Haag, T" <[email-masked]> 

26/09/2006 23:38 

To
<[email-masked]> 
cc
[email-masked] 
Subject
AW: [ANCP] Layer 2 Parameters in the Protocol document

Menachem, 
 
The usage of a VPI/VCI is really dependent on the use case you are
considering. 
Regarding the use case access line topology it is optional because there
is no strong relation to a layer 2 parameter if we report the net data
rate. 
 
But considering the use cases OAM (F5 LB for ADSL2/2plus) or line
configuration the layer 2 parameter such as VPI/VCI or VLAN is
essential. So I would recommend keeping these layer 2 parameters in the
format of the "Access-Loop-Circuit-ID". 
 
Regards 
 
Thomas 

________________________________

Von: [email-masked] [mailto:[email-masked]] 
Gesendet: Montag, 28. August 2006 15:57
An: [email-masked]; [email-masked]; [email-masked];
[email-masked]; Haag, Thomas; [email-masked]
Betreff: [ANCP] Layer 2 Parameters in the Protocol document 

Hi, 

      I have a question regarding the "Access-Loop-Circuit-ID" as
defined in the document
"draft-wadhwa-gsmp-l2control-configuration-01.txt". 

      In the case of an Ethernet based local loop the format is defined
as: 

      "Access-Node-Identifier eth slot/port[:vlan-id]" meaning that the
vlan-id is optional. 

      In the case of an ATM based local loop the format is defined as: 

      "Access-Node-Identifier atm slot/port:vpi.vci"  meaning that the
vpi.vci is mandatory. 

      I would like this changed to "Access-Node-Identifier atm
slot/port[:vpi.vci]" meaning that the vpi.vci is optional. 

      This would allow for multiple vpi/vci(s) on the same port as a
message could be sent  without the vpi.vci field. 

========================================================================
=== 

I have a similar question regarding the
"Access-Aggregation-Circuit-ID-ASCII" as defined in the document
"draft-wadhwa-gsmp-l2control-configuration-01.txt". 

      In the case of an Ethernet based local loop the format is defined
as: 

      "Access-Node-Identifier eth
slot/port[:inner-vlan-id][:outer-vlan-id]" meaning that the vlan-ids are
optional. 

      In the case of an ATM based local loop the format is defined as: 

      "Access-Node-Identifier atm slot/port:vpi.vci"  meaning that the
vpi.vci is mandatory. 

      I would like this changed to "Access-Node-Identifier atm
slot/port[:vpi.vci]" meaning that the vpi.vci is optional. 

Thank you kindly. 

Best Regards, 
Menachem _______________________________________________
ANCP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ancp

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