Re: [ANCP] ANCP Versioning - next steps; partition ID

Hi All,

I updated the ancp protocol draft following the chairs? recommendations on the ANCP versioning.

In particular:

I added some text to explain the history and rationale, at the end of section 2:

?At the time of writing of this specification some implementations of the ANCP protocol, based on pre-standards drafts are already available. All these early-draft implementations use protocol

version/sub-version 3.1; standard ANCP protocol will use version/

sub-version 3.2 [Editor's note: sub-version needs to be changed from

1 to 2 upon publication.] Adopting a new sub-version value provides

a way to disambiguate the two protocols and allows for supporting

running a pre-standard and a standards compliant ANCP implementation

on any given ANCP node. The mechanism used to identify the protocol

version/sub-version is part of the adjacency negotiation process and

it is described in details in Section 5.2. It is important to note

that this mechanism does not guarantee backwards compatibility of the

ANCP RFC specification to those early-draft implementations.?

I explained the version/sub-version negotiation process in section 5.2:

?ANCP uses version 3 and sub-version 1 of GSMP protocol.

[RFC Editor's note: sub-version needs to be changed from 1 to 2 upon

publication.] In the adjacency protocol the version and the sub-

version fields are used for version negotiation. The version

negotiation is performed before synchronisation is achieved. In a

SYN message the version/sub-version fields always contain the highest

version understood by the sender. A receiver receiving a SYN message

with a version/sub-version higher than understood will ignore that

message. A receiver receiving a SYN message with a version/

sub-vresion lower than its own highest version/sub-version, but a

version/sub-version that it understands, will reply with a SYNACK

with the version/sub-version from the received SYN in its ANCP version/sub-version fields. This defines the version/sub-version of

the ANCP protocol to be used while the adjacency protocol remains

synchronised. All other messages will use the agreed version in the

version/sub-version fields.?

I added a non-normative appendix. This appendix will contain a clarification of what version of the ANCP protocol draft specification constitutes version 3.1 as soon as the WG decides on 3.1

?6. Appendix: Handling of pre-RFC deployments of the ANCP protocol

This appendix is non normative.

Prior to completion of this document, several pre-RFC versions of the

protocol were documented and implemented. There were numerous pre-

standard versions of the protocol all using a version/sub-version

fields set to 3.1.

A NAS implementing the ANCP protocol as defined in this document may,

on a peer basis, use the version and sub-version fields to detect a

pre-RFC implementation of the protocol and choose to work with such

pre-RFC peers. The version and sub-version negotiation phase is part

of the adjacency protocol and is performed before synchronisation is

achieved.?

Please find new version of draft attached.

I hope I?ve captured most of your feedback in the new draft, if not or if you have additional comments please let me know.

Best Regards,

Roberta

From: ancp-bounces at ietf.org [mailto:ancp-bounces at ietf.org] On Behalf Of Wojciech Dec (wdec)
Sent: Wednesday, October 14, 2009 1:07 PM
To: ancp at ietf.org
Subject: [ANCP] FW: ANCP Versioning - next steps

Hi All,

During the ITEF75 WG meeting a discussion was had on ANCP protocol versioning and the need to revise the protocol version. A follow-up e-mail discussion on the WG alias took place and it seems appropriate now (if not overdue) to draw up a set of recommendations and settle the issue:

Recommended protocol draft changes and WG actions

- The currently used ANCP version 3.1 is to change to 3.2 at the time of publishing as an RFC. An instruction to execute such a change should be placed as part of an editors' note in the next revision of draft-ietf-ancp-protocol. This instruction is expected to only come into effect at the time of final review past a WG last-call, which means that until then v3.1 will be in evidence. Current implementers should make a note of this fact.

- Another note (not editorial though) should be placed in an appropriate section, possibly Section 2 or Section 5, to convey in-brief the historic aspect of GSMP/ANCP v3.1 implementations, which are (were?) based on early versions of the ANCP protocol draft. The note should be clear in offering no guarantees in terms of backwards compatibility of the RFC spec to those early-draft implementations. The note must also not be seen as passing a normative reference to the early protocol draft.

- Along with the above note, the existing GSMP/ANCP version negotiation mechanisms could be highlighted, indicating that it provides a way to distinguish between the different versions if the adjacency establishment negotiation mechanism followed by all is as per GSMPv3 (rfc3292).

- For the sake of clarity it is recommended that the adjacency negotiation be more fully described in the ANCP protocol draft instead of the current reference to rfc3292. Specifically, it would appear reasonable to adopt and re-edit Section 11.2 of rfc3292 into the ANCP protocol spec, with the re-edit describing the version negotiation behaviour. Rather confusingly Rfc3292 Section 11.2 does not carry text or logic statements as to the expected behaviour in case of version differences, but such text is in evidence in the descriptive part of Section 11.1.

- The WG should identify what version of the ANCP protocol draft specification constitutes v3.1. A non-normative reference to such a reference could be passed in the v3.2 spec.

Rationale

From a technical point of view, given that a "current" (i.e. draft-ietf-protocol-06 based) and future (i.e. ANCP RFC based) protocols are identical, with any newly added functions covered as negotiable capabilities, the version change does not appear to be fully warranted and not fully in line with the guidelines previously laid down (http://www.ietf.org/mail-archive/web/ancp/current/msg00152.html). That said, from an operational perspective a reasonable case for such a version change has made based and presented in https://svn.tools.ietf.org/agenda/75/slides/ancp-3/ancp-3_files/v3_document.htm.

Now, given that normative compliance to an interim draft (such as draft-ietf-protocol-06 based) cannot be passed by the ANCP RFC, text which may be perceived as mandating or claiming compatibility to such interim drafts needs to be avoided.

In the case of vendors and operators that already support/use v3.1 and have plans for v3.2, the version negotiation mechanism that ANCP inherited from GSMPv3 provides a way to disambiguate the two protocols and thus allows in theory for supporting running a pre-standard (v3.1) and a standards compliant v3.2 on any given ANCP node. The issue of where v3.1 is documented can be solved by using non-normative references to one of the interim drafts. The issue of what rev of draft-ietf-ancp is considered to be v3.1 needs to be clarified.

Other than the above the WG is currently not chartered to be extending the protocol spec to cover issues around protocol version negotiation or remediation of incompatibilities of draft implementations. As such no such work is expected.

We welcome clarification questions on the above.

Regards,
Wojciech & Matthew.