Subject: RE: [ANCP] Protocol version nummer for ANCP

From: "Steve Senum \(ssenum\)" <[email-masked]>
Date: Wed, 6 Dec 2006 11:23:42 -0500

Hi Thomas,

>  
> 
> -----Original Message-----
> From: Haag, T [mailto:[email-masked]] 
> Sent: Wednesday, December 06, 2006 5:46 AM
> To: Steve Senum (ssenum)
> Cc: [email-masked]; Hamacher, Peter
> Subject: AW: [ANCP] Protocol version nummer for ANCP
> 
> Steve,
> 
> Changing the TCP port has fundamental impact on basic decisions and also to already existing production code. 
> If I remember right it was decided to use basic functionality of GSMP. 

And then started changing it to meet your requirements...

> 
> To change a TCP port is from an operator's standpoint unacceptable because it affects adjacency and creates massive interoperability problems outside in the field.

>From a BRAS point of view, it would be fairly simple to
add another TCP listen for a new port.  The existing port could
then be left for draft 0, and the new port could be used for
the final RFC version.

With respect to the protocol version field being used,
consider the following.

Let say they are 20 draft versions of ANCP (yes, I have seen
the draft count go that high).  Let say every other one is
incompatible in some way, leaving 10 protocol versions,
all of which have to be documented in the RFC, and all of
which need to be tested and carried forward in the deployed
implementations.

Is that really what you want?

Regards,
Steve Senum

> 
> Regards
> Thomas
> 
> -----Ursprüngliche Nachricht-----
> Von: Steve Senum (ssenum) [mailto:[email-masked]] 
> Gesendet: Mittwoch, 6. Dezember 2006 00:48
> An: [email-masked]
> Betreff: RE: [ANCP] Protocol version nummer for ANCP
> 
> Hi,
> 
> Another comment on the current draft.  It specifies TCP
> port 6068 be used for incoming connections, which is the
> port defined for GSMPv3 (RFC 3292, RFC 3293).
> 
> I understand ANCP is based on GSMPv3, but given it seems
> to have evolved into something a bit different, perhaps
> a different TCP port should be assigned?
> 
> Regards,
> Steve Senum
> 
> _______________________________________________
> ANCP mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ancp
> 

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

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 06 Dec 2006 11:33:41 -0800

Without doubt, the upgrade problem needs to be
dealt with. The minimum that this working group
needs to do is to ensure that equipment talking the
protocol can distinguish different versions.
The simplest effective way to do that is to
use different version numbers.

The final RFC does not need to require interoperability
with old draft versions. Differences may be
documented as an appendix.

Regards,
Jakob Heitz.

---

From: "Haag, T" <[email-masked]>
Date: Thu, 7 Dec 2006 08:09:12 +0100

Steve,

Our requirement is very simple. 

If you develop a protocol please make sure that you don't provide fundamental changes in a way that interoperability with older versions gets lost.

If yes make sure that you provide a mechanism in the network element (e.g. using a version identifier) to solve the problem that network elements can interwork. 

To give you an actual example: 

Between two versions TLV 90 was changed in a way that previous version code the DSL TYPE. Newer version now codes the Encapsulation Type. For an operator is even that change fundamental because if you trigger on a DSL Type and receive an Encapsultation Type causes a mismatch.  

Regards
Thomas

-----Ursprüngliche Nachricht-----
Von: Steve Senum (ssenum) [mailto:[email-masked]] 
Gesendet: Mittwoch, 6. Dezember 2006 17:24
An: Haag, Thomas
Cc: Hamacher, Peter; [email-masked]
Betreff: RE: [ANCP] Protocol version nummer for ANCP

Hi Thomas,

Regards,
Steve Senum

---

From: "Michel Platnic" <[email-masked]>
Date: Thu, 7 Dec 2006 14:55:03 +0200

Hi All,

When modifications are brought to a protocol, in case they lead to interoperability issues then version/sub-version number should be used. Though, a document that has not become yet a working group text should not, in my opinion, have a dedicated version as it means that it needs to stay documented as an official version.
If we start incrementing version numbers, first ANCP version should probably be the RFC itself or at least a document that received the consensus of the group - maybe: draft-wadhwa-gsmp-l2control-configuration-02 if it becomes a working group text.

I would suggest that vendors who implemented previous ANCP draft versions (we are part of them) should find ways to synchronize versions between them for now.

Regards,
Michel.

-----Original Message-----
From: Haag, T [mailto:[email-masked]] 
Sent: Thursday, December 07, 2006 9:09 AM
To: [email-masked]
Cc: Hamacher, Peter; [email-masked]
Subject: AW: [ANCP] Protocol version nummer for ANCP

Steve,

Regards
Thomas

-----Ursprüngliche Nachricht-----
Von: Steve Senum (ssenum) [mailto:[email-masked]] 
Gesendet: Mittwoch, 6. Dezember 2006 17:24
An: Haag, Thomas
Cc: Hamacher, Peter; [email-masked]
Betreff: RE: [ANCP] Protocol version nummer for ANCP

Hi Thomas,

Regards,
Steve Senum

---

From: [email-masked]
Date: Thu, 7 Dec 2006 15:19:26 +0000

All,

Even if draft-wadhwa is a working group draft, it will not persist beyond
the publication of the ANCP RFC unless we decide at some point to publish
an early version as an informational or experimental RFC to reflect a
widespread deployment of that draft.

Either way, I think any standardised version numbers need to refer to
documents that will continue to be publically available beyond the lifetime
of this working group.

Matthew

"Michel Platnic" <[email-masked]> wrote on 07/12/2006 12:55:03:

> Hi All,
>
> When modifications are brought to a protocol, in case they lead to
> interoperability issues then version/sub-version number should be
> used. Though, a document that has not become yet a working group
> text should not, in my opinion, have a dedicated version as it means
> that it needs to stay documented as an official version.
> If we start incrementing version numbers, first ANCP version should
> probably be the RFC itself or at least a document that received the
> consensus of the group - maybe: draft-wadhwa-gsmp-l2control-
> configuration-02 if it becomes a working group text.
>
> I would suggest that vendors who implemented previous ANCP draft
> versions (we are part of them) should find ways to synchronize
> versions between them for now.
>
> Regards,
> Michel.
>
>
> If you develop a protocol please make sure that you don't provide
> fundamental changes in a way that interoperability with older
> versions gets lost.
>
> If yes make sure that you provide a mechanism in the network element
> (e.g. using a version identifier) to solve the problem that network
> elements can interwork.
>
> Between two versions TLV 90 was changed in a way that previous
> version code the DSL TYPE. Newer version now codes the Encapsulation
> Type. For an operator is even that change fundamental because if you
> trigger on a DSL Type and receive an Encapsultation Type causes a
mismatch.
> > Changing the TCP port has fundamental impact on basic decisions
> and also to already existing production code.
> > To change a TCP port is from an operator's standpoint unacceptable
> because it affects adjacency and creates massive interoperability
> problems outside in the field.
>