[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ANCP] ANCP Protocol Versioning

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: ancp-bounces at ietf.org [mailto:ancp-bounces at ietf.org] On Behalf Of Tom Taylor
Sent: Thursday, August 27, 2009 9:21 PM
To: HaagT at telekom.de
Cc: B.Witschurke at telekom.de; ancp at ietf.org; peter.arberg at ericsson.com; Robert.Rennison at ecitele.com; 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".
> ...
_______________________________________________
ANCP mailing list
ANCP at ietf.org
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.