Subject: [ANCP] FW: ANCP Versioning - next steps

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Wed, 14 Oct 2009 13:06:38 +0200

> 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_doc
> ument.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.

---

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

In general i support this way forward by adding "Informative Reference" to the ANCP Protocol Draft when going to WG last call.

Just for clarification, what is the reason for not offering guarantess for backward compatibility?

Alan

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Wojciech Dec (wdec)
Sent: October 14, 2009 7:07 AM
To: [email-masked]
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:

- 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.[Alan Kavanagh] Agree it makes sense to include the noted change of ANCP Version/Sub-version to 3.2 and agree that this should be captured in the current draft as an editors note.

- 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. [Alan Kavanagh]  Agree an Normative Reference should note the reason for change from 3.1 to 3.2 and I support the recommendation here, the most appropiate section i believe is Section 5 imho.

- 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).
[Alan Kavanagh]  Agree, though RFC 3292 does not have sub-version.

- 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.
[Alan Kavanagh] Agree, and this is what I proposed sometime back, though 3292 does currently not cover sub-version and this must be covered in the re-edited section to be included in the ancp protocol spec, For clarification, what is your recommendation for the adjacency negotiation? Is it to include the sub-version also?. 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.[Alan Kavanagh]  Therefore are you noting we should include text in the ANCP protocol draft as to what expected behaviour should be in the event of Version/sub-version differences?

- 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. [Alan Kavanagh]  Agree, will this be noted in the ANCP protocol draft as opposed to a reference pointer to RFC3292? 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.

Regards,
Wojciech & Matthew.

---

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

From: Alan Kavanagh [mailto:[email-masked]] 
	Sent: 14 October 2009 19:50
	To: Wojciech Dec (wdec); [email-masked]
	Subject: RE: ANCP Versioning - next steps

	In general i support this way forward by adding "Informative
Reference" to the ANCP Protocol Draft when going to WG last call. 
	 
	Just for clarification, what is the reason for not offering
guarantess for backward compatibility? 
	 
	Woj> Since there in effect is no standard for v3.1, and there
won't be one, it's unclear as to how any form of backwards compatibility
could be guaranteed 
	 
	-Woj.
	 
	Alan

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Wojciech Dec (wdec)
	Sent: October 14, 2009 7:07 AM
	To: [email-masked]
	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:

	- 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.[Alan Kavanagh] Agree it makes sense to include the
noted change of ANCP Version/Sub-version to 3.2 and agree that this
should be captured in the current draft as an editors note. 

	- 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. [Alan Kavanagh]  Agree an Normative Reference should note the
reason for change from 3.1 to 3.2 and I support the recommendation here,
the most appropiate section i believe is Section 5 imho.

	- 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).
	[Alan Kavanagh]  Agree, though RFC 3292 does not have
sub-version.

	- 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. 
	[Alan Kavanagh] Agree, and this is what I proposed sometime
back, though 3292 does currently not cover sub-version and this must be
covered in the re-edited section to be included in the ancp protocol
spec, For clarification, what is your recommendation for the adjacency
negotiation? Is it to include the sub-version also?. 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.[Alan Kavanagh]
Therefore are you noting we should include text in the ANCP protocol
draft as to what expected behaviour should be in the event of
Version/sub-version differences? 

	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
<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_docum
ent.htm
<https://svn.tools.ietf.org/agenda/75/slides/ancp-3/ancp-3_files/v3_docu
ment.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. [Alan Kavanagh]  Agree, will this be noted in the ANCP protocol
draft as opposed to a reference pointer to RFC3292? 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.

	Regards, 
	Wojciech & Matthew.

---

From: Maglione Roberta <[email-masked]>
Date: Mon, 19 Oct 2009 16:16:24 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf Of Wojciech Dec (wdec)
Sent: Wednesday, October 14, 2009 1:07 PM
To: [email-masked]
Subject: [ANCP] FW: ANCP Versioning - next steps

Hi All,

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

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

Rationale

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.

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.

Rispetta l'ambiente. Non stampare questa mail se non ? necessario.

---

From: <[email-masked]>
Date: Wed, 28 Oct 2009 15:52:11 +0100

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:[email-masked]] 
Gesendet: Montag, 19. Oktober 2009 16:16
An: 'Wojciech Dec (wdec)'; [email-masked]; Haag, Thomas; [email-masked]; [email-masked]; [email-masked]; BOCCI Matthew; [email-masked]'
Betreff: RE: ANCP Versioning - next steps

Hi All,

In particular:

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

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

   fields set to 3.1.

   achieved."

Best Regards,

Roberta

  _____  

 

Hi All, 

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> 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> https://svn.tools.ietf.org/agenda/75/slides/ancp-3/ancp-3_files/v3_document.htm. 

Regards, 
Wojciech & Matthew. 

rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: Alan Kavanagh <[email-masked]>
Date: Thu, 29 Oct 2009 13:36:16 -0400

Hi Roberta et.al

Thomas is correct, from the notes of the San Fran meeting we agreed to keep the Partition ID section, so can you please reinsert this.

BR
Alan

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: October 28, 2009 10:52 AM
To: [email-masked]; [email-masked]; [email-masked]; Alan Kavanagh; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: AW: ANCP Versioning - next steps; partition ID

Hi Roberta, all,

(1) Partition-id
    ------------

Regards

Thomas
.

Hi All,

Best Regards,
Roberta

Hi All,

Rationale

Regards,
Wojciech & Matthew.

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Thu, 29 Oct 2009 19:45:22 +0100

While keeping the GSMP derived partition-id in the protocol spec "as is" is fine, a note should perhaps also be inserted stating that this field is effectively not currently used by ANCP. At least this is my recollection of the discussion on this matter, ie partition-id is fine, but we don't really have a use for it now given that functional partitioning is not covered and that an AN will have 1 adjacency to each NAS/controller.
 
-Woj.

	From: [email-masked] [mailto:[email-masked]] 
	Sent: 28 October 2009 15:52
	To: [email-masked]; Wojciech Dec (wdec); [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
	Subject: AW: ANCP Versioning - next steps; partition ID

	Hi Roberta, all,

	 

	(1) Partition-id
	    ------------

	 
	Regards
	 
	Thomas
	. 

	Hi All,

	In particular:

	   fields set to 3.1.

	   achieved."

	Best Regards,

	Roberta

	 

	Hi All, 

	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 <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 <https://svn.tools.ietf.org/agenda/75/slides/ancp-3/ancp-3_files/v3_document.htm> . 

	Regards, 
	Wojciech & Matthew.

---

From: "Reith, Lothar" <[email-masked]>
Date: Fri, 30 Oct 2009 17:16:50 +0100

Hi Woj, dear all,
 
I fully support Thomas Haag`s point in his mail.
 
I also noticed that the following section is no longer present in the current version, and propose to re-include:
 
Partition ID:

      This field is a 8 bit number which signifies a partition on the
      AN. [ TBD How AN and NAS agree on the partition numbers.  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.]

I further suggest to enhance the text as follows:
 
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.

A potential use case could be in assurance, e.g. to enable verification that the proper (intended) partition ID is used over a particular adjacency in cases where the AN has multiple adjacencies to different NAS/Controller. 
 
 Best Regards, Lothar Reith
 
Detecon International GmbH (Deutsche Telekom Group)

	Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Wojciech Dec (wdec)
	Gesendet: Donnerstag, 29. Oktober 2009 19:45
	An: Haag, Thomas; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Paul, Manuel; Witschurke, Birgit
	Betreff: Re: [ANCP] ANCP Versioning - next steps; partition ID

	-Woj.

		Hi Roberta, all,

		 

		(1) Partition-id
		    ------------

		 
		Regards
		 
		Thomas
		. 

		Hi All,

		In particular:

		   fields set to 3.1.

		   achieved."

		Best Regards,

		Roberta

		 

		Hi All, 

		Rationale 

		Regards, 
		Wojciech & Matthew.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Fri, 30 Oct 2009 18:19:20 +0100

Hi Lothar,
 
Having the NAS/controller verify the sender-name (as is done today), with each partition using a different sender name, would accomplish the use-case below, without partition-id. Any problem with this?
 
Thanks,
Woj.

	From: Reith, Lothar [mailto:[email-masked]] 
	Sent: 30 October 2009 17:17
	To: Wojciech Dec (wdec); Haag, Thomas; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Paul, Manuel; Witschurke, Birgit
	Subject: AW: [ANCP] ANCP Versioning - next steps; partition ID

	Hi Woj, dear all,

	 
	Partition ID:

	

	Partition ID:

	

	 

		 
		-Woj.

			Hi Roberta, all,

			 

			(1) Partition-id
			    ------------

			 
			Regards
			 
			Thomas
			. 

			Hi All,

			In particular:

			   fields set to 3.1.

			   achieved."

			Best Regards,

			Roberta

			 

			Hi All, 

			Rationale 

			Regards, 
			Wojciech & Matthew.