Re: GSMPv3 and L2C

Hi,

Answers in line.


> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-gsmp-v3-base-spec-06.txt
On 30 jan 2005, at 01.50, Sanjay Wadhwa wrote:

> DSL Forum is working on a protocol for interaction between 
> access-nodes(e.g DSLAMs) and BRAS devices (controllers in gsmp-speak) 
> in an atm or ethernet based access networks.
> Avri had posted on the list the DSL forum draft on this work (L2CP - 
> L2 control protocol). The idea is to extend GSMPv3 to implement 
> requirements of the L2 control protocol.
> In going through the current GSMP RFCs, and the DSL forum document a 
> couple of observations :
>
> 1. GSMP RFCs suggests that switch is the passive entity with respect 
> to tcp connectivity. The controller initiates the TCP connection. In 
> certain cases (e.g in L2C it makes sense to let the controller be 
> passive w.r.t TCP connection, and let the access-node(s) initiate TCP 
> connection).  Does it make sense for the GSMP spec to not require that 
> controller initiate the tcp connection  but keep it be open such that 
> this behaviour can be config driven on the devices involved. The 
> applicability document can capture specifics of different 
> applications.

Unless I misremember, there is nothing in the adjacency protocol that 
determines that the first SYN need to be sent out by the controller as 
opposed to the switch.  the may be part of TCP framing method, but I 
don't think it is integral to the protocol  so I guess my answer is, 
yes, I think this could be worked out.


>
> 2. The adjacency protocol in GSMP has version number negotiation 
> support. Was there any discussion when GSMP was being designed to take 
> a more general approach to capability negotiation between the swtich 
> and controller (e.g  by including capability TLVs in adjacency 
> protocol messages) ? This helps extensibility in general.

Yes, there was.  For reasons of complexity we decided to make it simply 
version number  negotiation (and i need to get rid of the subversion 
number - i have been convinced this is a bad idea ).  My operating 
assumption is that options are limited to a technology specific 
extension and we can certainly talk about it in that context.

>
> Will appreciate feedback (including general discussion on extending 
> GSMPv3 to implement L2C as specified in the DSL forum doc)...

I recommend you look at draft-ietf-v3-gsmp-base-spec which contains the 
base modifications which i think should be the start for any changes to 
we make to support DSL.

I have looked at the DSL doc and think the work is definitely 
reasonable.  I am waiting, with infinite patience, to see if there are 
others on this list who think so.  I currently have limited bandwidth 
(code words for no employer interested in paying for this work) for 
making changes to the protocol, though i am ready to edit the base 
document in my own time once people figure out what changes they need 
to the base.

As far as I can tell, we need someone to take on the task of writing 
the DSl specific section of the doc to go with the base protocol spec.  
In the writing of the DSL technology specific section we will come up 
with issues where the base doesn't support what is needed.  At that 
point I will negotiate the changes with whoever wishes to negotiate.

cheers,

a.