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

From: "Reith, Lothar" <[email-masked]>
Date: Mon, 2 Nov 2009 10:39:27 +0100

Hi Woj,
 
I am afraid that your proposal means that we should use  "sender-name" instead of "partition-ID" to identify an AN partition.
 
Known implementations use  "sender-name" to convey either the management name of the AN (and the NAS/Controller respectively) or a MAC address as GSMPv3 describes.
 
So for two reasons it is not possible to use "sender name" instead of "partition ID":
 
1. The associated functionality to verify if one is talking to the proper (intended) AN (or NAS/Controller respectively) 
    would be lost if when using the sender-id to convey the partition-ID instead of the management name of the device.

2. If a MAC address information in "sender name" would be used for "partition ID" only one partition can be used because usually a AN uses one MAC address. So we have a conflict on networking because usually an access node use one MAC Adresse regardles of partitioning. 
 
For that reasons I don't want to effectively abandon the partition-ID. I highly recommend keeping the conventions (75th meeting minutes) for partition ID as I understand they are meant to keep network scenarios clean and avoid the mixing up of different layer informations.
 
Best Regards,
 
Lothar Reith
Detecon International GmbH (Deutsche Telekom Group)

________________________________

	Von: Wojciech Dec (wdec) [mailto:[email-masked]] 
	Gesendet: Freitag, 30. Oktober 2009 18:19
	An: Reith, Lothar; 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

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

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

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

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

				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 

				"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, 

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

				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. 

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

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Mon, 2 Nov 2009 14:54:26 +0100

Hi Lothar,

From: Reith, Lothar [mailto:[email-masked]] 
Sent: 02 November 2009 10:39
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,

	 
	Woj> The choice of what goes into the sender-name is rather arbitrary; having a name + partition-id is pretty much as the same as having a name with partition-id.
	Furthermore, we're now at v3.2 of ANCP...

	 
	Woj> How so? The name is an opaque value that has significance to the operator, very much like partition-id.

	Woj> Please note that GSMP recommended the use of MAC addresses because it was meant to run on TCP/IP. In ANCP , you can identify each AN with the IP address and the sender-name is pretty much redudnant today. However it appears it could well be used for the use-case you described.

	Woj> The existing "conventions" amount to partition-id beingthere, like other GSMP fields, but its use is not currently specified in ANCP.
	 
	Regards,
	Woj. 
	 
	Best Regards,
	 
	Lothar Reith

		Hi Lothar,

		Thanks,
		Woj.

			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.

---

From: <[email-masked]>
Date: Mon, 2 Nov 2009 16:09:27 +0100

All,
 
I'm really concerned about the way partition ID is beeing discussed now. 
The use of partitioning is described in ANCP Framework - final version.
Considering chapter 4.6.1 General Architecture, R-37,38,39,40 specifies exactly requirements for partitioning which is naturally served by using of an appropriate partition ID. 
>From my understanding ANCP protocol draft must follow ANCP framework requirements not having diverge work.
 
Derived from given descriptive text from ANCP framework it would be very useful for introduction in chapter "partition ID":
 
Textproposal:
 "The Access Node Control Mechanism is defined to operate between an Access Node (AN) and a NAS.  In such a model, the physical AN needs to be split in virtual ANs, each having
   its own Access Node Control reporting and/or enforcement function. A partition ID is used for seperation of different partions in one physical access node." 

As agreed in San Francisco minutes the partition ID remains as protocol field.
I strongly insist on following that agreement and keeping this field in protocol draft.

Regards
Thomas

  _____  

Von: Wojciech Dec (wdec) [mailto:[email-masked]] 
Gesendet: Montag, 2. November 2009 14:54
An: Reith, Lothar; 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

Hi Lothar,
 
  _____  

 

Hi Woj,

 

 

 

Regards,
Woj. 
 
Best Regards,
 
Lothar Reith

  _____  

Hi Lothar,

Thanks,
Woj.

  _____  

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 

>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: "Wojciech Dec (wdec)" <[email-masked]>
Date: Tue, 3 Nov 2009 12:49:41 +0100

Hi Thomas,
 
the framework is an informative document whose purpose is (was) used to help the WG steer at a high level the protocol design. Previous discussions have not revealed that a partition-id is needed, hence the "legacy status" of the partition field. It's perhaps also worth noting that current implementations largely do not support it. 
The latest discussion about the use-case from Lothar is a new one (and the use-case is not part of the framework), which is welcome to continue. As discussed so far, there appears to be another way for realizing this use-case, which does not require any new functionality. More opinions along with reasons are welcome.
 
Thanks,
Woj.

	From: [email-masked] [mailto:[email-masked]] 
	Sent: 02 November 2009 16:09
	To: Wojciech Dec (wdec); [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
	Subject: AW: [ANCP] ANCP Versioning - next steps; partition ID

	All,

	 
	Textproposal:

	Regards
	Thomas

	Hi Lothar,

		 
		
		Hi Woj,

		 

		 

		 

		Regards,
		Woj. 
		 
		Best Regards,
		 
		Lothar Reith

			Hi Lothar,

			Thanks,
			Woj.

				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.

---

From: Maglione Roberta <[email-masked]>
Date: Wed, 4 Nov 2009 10:51:13 +0100

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:

      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:

Please let me know,
thanks.
Best Regards,
Roberta

________________________________________
From: [email-masked] [[email-masked]]
Sent: Wednesday, October 28, 2009 3:52 PM
To: Maglione Roberta; [email-masked]; [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,
     I updated the ancp protocol draft following the chairs’ recommendations on the ANCP versioning.
In particular:

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

   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

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

Regards,
Wojciech & Matthew.

---

From: <[email-masked]>
Date: Wed, 4 Nov 2009 11:03:30 +0100

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:[email-masked]] 
Gesendet: Mittwoch, 4. November 2009 10:51
An: Haag, Thomas; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; 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:

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:

Please let me know,
thanks.
Best Regards,
Roberta

Hi Roberta, all,

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

Regards

Thomas
.

Hi All,

Best Regards,
Roberta

Hi All,

Rationale

Regards,
Wojciech & Matthew.

---

From: "Reith, Lothar" <[email-masked]>
Date: Wed, 4 Nov 2009 11:53:06 +0100

Hi Roberta, all,

I also support to re-insert the Partition ID options, and welcome your suggestion to adopt my respective wording proposal.

Best Regards, Lothar Reith 
Detecon International GmbH 

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Maglione Roberta
Gesendet: Mittwoch, 4. November 2009 10:51
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

Hi All,

Partition ID:

Please let me know,
thanks.
Best Regards,
Roberta

Hi Roberta, all,

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

Regards

Thomas
.

Hi All,

 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

Best Regards,
Roberta

Hi All,

Rationale

Regards,
Wojciech & Matthew.

_______________________________________________
ANCP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ancp

---

From: Hongyu Li <[email-masked]>
Date: Thu, 05 Nov 2009 20:41:21 +0800

Hi all,
 
I am working on a gap analysis between current ANCP and BBF TR-147, which is
the igniter. Partition is an important feature required by TR-147. It would
push ANCP farther away from TR-147 if we lose this feature.
As for identification of a partition, I would strongly support keeping
partition ID. Technically, "sender-name" may be used to identify partitions.
However, the 48 bits "sender-name" is 8 times longer as the 8 bits
"partition ID". This tells that "sender-name" is more for a global
identification of the peer of an AN control adjacency and may be globally
unique for management purpose, while "partition ID" is a local ID and may be
repeated over Access Nodes. 
Replacing partition ID by "sender-name" will actually extend the length of
partition ID by no benefits. Keeping both "sender-name" and "partition ID"
as is offers us a protocol with clear hierarchies and better expandability.
 
Hongyu

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Wojciech Dec (wdec)
Sent: Tuesday, November 03, 2009 7:50 PM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: [ANCP] ANCP Versioning - next steps; partition ID

Hi Thomas,
 
the framework is an informative document whose purpose is (was) used to help
the WG steer at a high level the protocol design. Previous discussions have
not revealed that a partition-id is needed, hence the "legacy status" of the
partition field. It's perhaps also worth noting that current implementations
largely do not support it. 
The latest discussion about the use-case from Lothar is a new one (and the
use-case is not part of the framework), which is welcome to continue. As
discussed so far, there appears to be another way for realizing this
use-case, which does not require any new functionality. More opinions along
with reasons are welcome.
 
Thanks,
Woj.

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: 02 November 2009 16:09
To: Wojciech Dec (wdec); [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: AW: [ANCP] ANCP Versioning - next steps; partition ID

All,
 
I'm really concerned about the way partition ID is beeing discussed now. 
The use of partitioning is described in ANCP Framework - final version.
Considering chapter 4.6.1 General Architecture, R-37,38,39,40 specifies
exactly requirements for partitioning which is naturally served by using of
an appropriate partition ID. 
>From my understanding ANCP protocol draft must follow ANCP framework
requirements not having diverge work.
 
Derived from given descriptive text from ANCP framework it would be very
useful for introduction in chapter "partition ID":
 
Textproposal:
 "The Access Node Control Mechanism is defined to operate between an Access
Node (AN) and a NAS.  In such a model, the physical AN needs to be split in
virtual ANs, each having
   its own Access Node Control reporting and/or enforcement function. A
partition ID is used for seperation of different partions in one physical
access node." 

As agreed in San Francisco minutes the partition ID remains as protocol
field.
I strongly insist on following that agreement and keeping this field in
protocol draft.

Regards
Thomas

  _____  

Von: Wojciech Dec (wdec) [mailto:[email-masked]] 
Gesendet: Montag, 2. November 2009 14:54
An: Reith, Lothar; 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

Hi Lothar,
 
  _____  

From: Reith, Lothar [mailto:[email-masked]] 
Sent: 02 November 2009 10:39
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,
 
I am afraid that your proposal means that we should use  "sender-name"
instead of "partition-ID" to identify an AN partition.
 
Known implementations use  "sender-name" to convey either the management
name of the AN (and the NAS/Controller respectively) or a MAC address as
GSMPv3 describes.
 
Woj> The choice of what goes into the sender-name is rather arbitrary;
having a name + partition-id is pretty much as the same as having a name
with partition-id.
Furthermore, we're now at v3.2 of ANCP...
 
So for two reasons it is not possible to use "sender name" instead of
"partition ID":
 
1. The associated functionality to verify if one is talking to the proper
(intended) AN (or NAS/Controller respectively) 
    would be lost if when using the sender-id to convey the partition-ID
instead of the management name of the device. 
 
Woj> How so? The name is an opaque value that has significance to the
operator, very much like partition-id.

2. If a MAC address information in "sender name" would be used for
"partition ID" only one partition can be used because usually a AN uses one
MAC address. So we have a conflict on networking because usually an access
node use one MAC Adresse regardles of partitioning.  
 
Woj> Please note that GSMP recommended the use of MAC addresses because it
was meant to run on TCP/IP. In ANCP , you can identify each AN with the IP
address and the sender-name is pretty much redudnant today. However it
appears it could well be used for the use-case you described.
 
For that reasons I don't want to effectively abandon the partition-ID. I
highly recommend keeping the conventions (75th meeting minutes) for
partition ID as I understand they are meant to keep network scenarios clean
and avoid the mixing up of different layer informations. 
 
Woj> The existing "conventions" amount to partition-id beingthere, like
other GSMP fields, but its use is not currently specified in ANCP.
 
Regards,
Woj. 
 
Best Regards,
 
Lothar Reith

  _____  

Von: Wojciech Dec (wdec) [mailto:[email-masked]] 
Gesendet: Freitag, 30. Oktober 2009 18:19
An: Reith, Lothar; 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

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,

I also noticed that the following section is no longer present in the
current version, and propose to re-include:
 
Partition ID:

 
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:

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. 

  _____  

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

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,

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.

(1) Partition-id
    ------------
Thomas Haag: need multiple partition-ids because one might need to
distinguish 

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,

     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

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

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

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

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, 

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.

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

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.

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'ambienteRispetta l'ambiente. Non stampare questa mail se non è
necessario.