Subject: Re: [ANCP] ANCP Protocol Versioning

From: Maglione Roberta <[email-masked]>
Date: Mon, 12 Oct 2009 10:36:51 +0200

Hello Thomas and All,

>> [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.

Regarding this point I agree with Tom Taylor, pre-standard versions have no effect for the standard, thus in my opinion we should not add text that refers to pre-standard version in the current protocol draft.

In addition according to the meeting minutes, during last meeting the working group decided to change the version number to 3.2, but only upon publication of the RFC.
My understanding from the meeting and from the MM was that this will be done by adding an RFC Editor's note to change version from 3.1 to 3.2 upon publication.

Best Regards,
Roberta

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tom Taylor
Sent: Thursday, August 27, 2009 9:21 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [ANCP] ANCP Protocol Versioning

Comments below, marked with [PTT].

[email-masked] 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".
> ...
_______________________________________________
ANCP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ancp

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: Alan Kavanagh <[email-masked]>
Date: Wed, 14 Oct 2009 13:57:48 -0400

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:[email-masked]] 
Sent: August 27, 2009 3:21 PM
To: [email-masked]
Cc: [email-masked]; Alan Kavanagh; [email-masked]; Peter Arberg; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [ANCP] ANCP Protocol Versioning

[email-masked] wrote:
> 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
> 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.
> 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:
> 
> session.  ANCP must use sub-version 2 of the GSMP protocol. [T.H]:Pre 
> RFC implemtations must use sub-version 1.
> 
> 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.
>

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Thu, 15 Oct 2009 11:25:58 +0200

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.

> From: Alan Kavanagh [mailto:[email-masked]] 
> Sent: 14 October 2009 19:58
> To: Tom Taylor; [email-masked]
> Cc: [email-masked]; [email-masked]; Peter 
> Arberg; Wojciech Dec (wdec); [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> 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
> 
> 
> Cc: [email-masked]; Alan Kavanagh; 
> [email-masked]; Peter Arberg; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> [PTT] By definition, pre-standard versions do not conform to 
> the standard, so this text will have no effect.
> >