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

[<HaagT at telekom.de>]

Roberta, all,

Thanx for clarification, I noticed the changes which triggered my comment

I strongly support keeping also the options as they are because it was no agreement to delete them.

Regards
Thomas

-----Ursprüngliche Nachricht-----
Von: Maglione Roberta [mailto:roberta.maglione at telecomitalia.it] 
Gesendet: Mittwoch, 4. November 2009 10:51
An: Haag, Thomas; wdec at cisco.com; ancp at ietf.org; alan.kavanagh at ericsson.com; Robert.Rennison at ecitele.com; swadhwa at juniper.net; matthew.bocci at alcatel-lucent.co.uk; tom111.taylor at bell.net; Paul, Manuel; Witschurke, Birgit
Betreff: RE: ANCP Versioning - next steps; partition ID

Hi All,
   Just a clarification on Partition-Id:
Version 07 of the protocol  still contains Partition-Id field and original definition, on page 18, I didn't remove the partition ID field I've just deleted the two options to select  this value, on page 18:
"   Partition ID:

      This field is a 8 bit number which signifies a partition on the
      AN.

My understanding from SF meeting "No one felt strongly -- will keep "as is" was that we keep current definition of Partition ID as it was originally, thus I removed the two options. If the WG feels we need the two options I can update the draft with the text proposed by Rothar:

Partition ID:

      This field is a 8 bit number which signifies a partition on the
      AN.  AN and NAS MAY agree on the partition ID using one of the following possible
      options:

      1 - The partition ID could be configured on the AN and learnt by
      NAS in the adjacency message;

      2 - The partition ID could be statically configured on the NAS as
      part of configuring the neighbor information.

Please let me know,
thanks.
Best Regards,
Roberta

________________________________________
From: HaagT at telekom.de [HaagT at telekom.de]
Sent: Wednesday, October 28, 2009 3:52 PM
To: Maglione Roberta; wdec at cisco.com; ancp at ietf.org; alan.kavanagh at ericsson.com; Robert.Rennison at ecitele.com; swadhwa at juniper.net; matthew.bocci at alcatel-lucent.co.uk; tom111.taylor at bell.net; Manuel.Paul at telekom.de; B.Witschurke at telekom.de
Subject: AW: ANCP Versioning - next steps; partition ID

Hi Roberta, all,

thanks for providing the updated protocol draft.

So far I recognized that the update covers issues regarding versioning, tech Type for GPON and Range of values of the code field.

But I notice on page 17 of version 07 that the whole section of partition ID including definition is deleted.
From my understanding (and as result from the minutes) it was agreed during 75th IETF meeting to keep the partition ID.

Extract from 75th IETF minutes:

(1) Partition-id
    ------------
Sanjay: concerned that removing the partition-id reduces extensibility.
Thomas Haag: need multiple partition-ids because one might need to distinguish
between BRASs when expanding the network.
Woj: send e-mail. Thomas: already did. Makes for operational problems
if partition-id not available.
No one felt strongly -- will keep "as is".

So we had consensus not to remove and keep partion ID. But I didn't find it in the whole document any more.
Based on that agreements I wonder why this issue is deleted. Are there any reasons for doing this?

So I recommend update the protocol draft before upcoming meeting keeping partition ID.

Regards

Thomas
.


________________________________
Von: Maglione Roberta [mailto:roberta.maglione at telecomitalia.it]
Gesendet: Montag, 19. Oktober 2009 16:16
An: 'Wojciech Dec (wdec)'; ancp at ietf.org; Haag, Thomas; alan.kavanagh at ericsson.com; Robert.Rennison at ecitele.com; swadhwa at juniper.net; BOCCI Matthew; 'tom111.taylor at bell.net'
Betreff: RE: ANCP Versioning - next steps

Hi All,
     I updated the ancp protocol draft following the chairs' recommendations on the ANCP versioning.
In particular:

 1.  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."

 1.  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."


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

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.

[cid:906131214@28102009-136B]Rispetta l'ambiente. Non stampare questa mail se non è necessario.



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.