Re: [ANCP] ANCP Protocol Versioning

[Alan Kavanagh <alan.kavanagh at ericsson.com>]

Hi Tom and Thomas

From a recent email sent by Woj, I support Thomas Haag's text as input into the re-edited sections for clarifying the ANCP Protocol versioning number issue and I agree with Thomas' proposed text. Additional text is required for clarifying the Adjacency Protocol negotiation in ANCP as noted by the Woj's email. 

Alan


-----Original Message-----
From: Tom Taylor [mailto:tom.taylor at rogers.com] 
Sent: August 27, 2009 3:21 PM
To: HaagT at telekom.de
Cc: Robert.Rennison at ecitele.com; Alan Kavanagh; lihy at huawei.com; Peter Arberg; wdec at cisco.com; swadhwa at juniper.net; ancp at ietf.org; B.Witschurke at telekom.de; Peter.Hamacher at telekom.de
Subject: Re: [ANCP] ANCP Protocol Versioning

Comments below, marked with [PTT].

HaagT at telekom.de wrote:
> All,
> 
> All exchanged arguments are valid.
> 
> I think a protocol draft describes protocol issues, values, TLV, etc. 
> and not network element mechanisms. The challenge now would be to 
> cover notes pointing out how to code pre version and RFC version - 
> that was agreed last meeting.
> 
> But what's missing in that game is a short description that both peers 
> (BRAS & AN) need to identify which SW version to choose based on sub version value.
>  A mechnism in detail for detection and automatic SW load depending on 
> sub version is neccessary.
> 
> I'm not sure if that is in scope of a protocol draft or if it should 
> be described seperately. But keeping the time line of protocol draft 
> and avoiding delaying ANCP work it may be desirable to identify 
> sections in protocol draft where notes are useful to detail that issue 
> without changing sections and order of the document.
> 
>> From my understanding three sections are concerned. I propose adding 
>> the notes at that sections.
> 
> Please see below the identified sections and added notes taken based 
> on protocol draft 05 for discussion:
> 
> Regards Thomas
> ----------------------------------------------------------------------
> -----------
> 
> 
> Chapter 2 Introduction / page 4:
> 
> ...
> 
> Not all the fields in relevant GSMP messages are used by ANCP.  This 
> draft indicates the value that ANCP should set for the fields in these 
> GSMP messages.
> 
> 
> 
> [T.H.:] Note: Implementations which use GSMP and ANCP conventions 
> before RFC publication must use sub-version 1.

[PTT] By definition, pre-standard versions do not conform to the standard, so this text will have no effect.
> 
> RFC based implementations must use sub-version 2. For details see chapter 5.
> 
> ...
> 
> ----------------------------------------------------------------------
> --------------
> 
> 
> Chapter 5. Access Node Control Protocol (ANCP) / page 15
> 
> ...
> 
> The 8-bit version field in the base GSMPv3 message header is split 
> into two 4 bit fields for carrying the version and a sub-version of 
> the GSMP protocol.  ANCP uses version 3 and sub-version 1 of the GSMP 
> protocol.  An ANCP implementation SHOULD always set the version field 
> to 3, and the sub-version field to 1.  The Result field in the message 
> header has been modified to be 4 bits long, and the Code field to be 
> 12 bits long.
> 
> Version:
> 
> The version number of the GSMP protocol being used in this session.  
> ANCP uses version 3.
> 
> Sub-Version:
> 
> The sub-version number of the GSMP protocol being used in this 
> session.  ANCP must use sub-version 2 of the GSMP protocol. [T.H]:Pre 
> RFC implemtations must use sub-version 1.
> 
[PTT] Same comment as above.
> 
> ---------------------------------------------------------------------
> 
> Chapter 5.1.  ANCP/TCP connection establishment / Page 19:
> 
> ...
> 
> NAS listens for incoming connections from the access nodes.  Port 6068 
> is used for TCP connection.  Adjacency protocol messages, which are 
> used to synchronize the NAS and access-nodes and maintain handshakes, 
> are sent after the TCP connection is established.  ANCP messages other 
> than adjacency protocol messages may be sent only after the adjacency 
> protocol has achieved synchronization.
> 
> [T.H.]:Note: NAS must detect per peer the sub version and must load 
> and synchronize with appropriate protocol implementation.
> 
[PTT] I would add "if possible".
> ...