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

From: "Haag, T" <[email-masked]>
Date: Thu, 7 Dec 2006 15:43:17 +0100

Peter,

I think you shift the discussion now to a level I would like to avoid. 
I want to point out that we don't have the business advantage only. You as vendor have also the advantage of getting a lot interoperability experience driven by our initiative.

But I would like to come back to technical issues:
The facts are already discussed and I receive also some vendor's feedback that this can be solved. 

So it seems to me not to be a technical problem any more. It is only the question to find the common way to agree on a solution. 

Thomas

-----Ursprüngliche Nachricht-----
Von: Busschbach, Peter B (Peter) [mailto:[email-masked]] 
Gesendet: Donnerstag, 7. Dezember 2006 15:20
An: Haag, Thomas; [email-masked]
Cc: Hamacher, Peter; [email-masked]
Betreff: RE: [ANCP] Protocol version nummer for ANCP

Thomas,

All due respect, but I really don't think you can require the working group to take into account any non-standard protocols that you decided to deploy in your network.

The fact that vendors and operators have pre-standard versions of protocols that they would like to salvage is a well-known dynamic in the standardization process, but all parties know that until a standard is officially accepted, anything can change. That is the risk of being first in the market: you have a business advantage, but you may pay the price in terms of incompatibility and upgrade problems.

The notion that version numbers and port numbers MUST be chosen in such a way as to accomodate users of non-standard protocol implementations is, as far as I know, unprecedented. This is a slippery slope which I think the working group should avoid. Same for suggestions that the working group should document the differences between the eventual protocol and non-standard versions.

Peter

> -----Original Message-----
> From: Haag, T [mailto:[email-masked]]
> Sent: Thursday, December 07, 2006 2:09 AM
> To: [email-masked]
> Cc: Hamacher, Peter; [email-masked]
> Subject: AW: [ANCP] Protocol version nummer for ANCP
> 
> 
> 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,
> 
> >  
> > 
> > -----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
> 
> _______________________________________________
> 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: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 7 Dec 2006 09:19:39 -0500

Thomas,

Peter