Re: [ANCP] ANCP Protocol Versioning

["Wojciech Dec (wdec)" <wdec at cisco.com>]

Please note that the text proposed largely has no effect (as also
observed by Tom), and is actually worded in normative terms (MUST...,
etc). As such I'd advise the editors to use any of the text at their
down discretion and likely come up with alternative wording.

-Woj.



> -----Original Message-----
> From: Alan Kavanagh [mailto:alan.kavanagh at ericsson.com] 
> Sent: 14 October 2009 19:58
> To: Tom Taylor; HaagT at telekom.de
> Cc: Robert.Rennison at ecitele.com; lihy at huawei.com; Peter 
> Arberg; Wojciech Dec (wdec); swadhwa at juniper.net; 
> ancp at ietf.org; B.Witschurke at telekom.de; Peter.Hamacher at telekom.de
> Subject: RE: [ANCP] ANCP Protocol Versioning
> 
> 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".
> > ...
>