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

From: "Steve Senum \(ssenum\)" <[email-masked]>
Date: Fri, 1 Dec 2006 18:00:44 -0500

Hi Thomas,

Haag, T [mailto:[email-masked]] wrote:
> 
> Steve, all,
> 
> That's the big difference between theory and practice.
> 
> Best practice to get running a new protocol is to implement first code check and improve it. But to manage the improvement a version negotiation can not be avoided because of already existing code which is not only present in a laboratory. 
> 
> To set all systems in the field to a new code seems a little bit different to update thousands of access nodes and related BNGs at the same time. I've never seen this running outside in the field. 
> 
> Again, I highly recommend thinking about. May be in the past this was not accepted, but the future is now. From a operator standpoint the business is too fast to wait until a draft has become a RFC is finalized. 

This problem is nothing new, and has probably been an issue with
almost every major protocol deployed.

> 
> You can not from a vendor standpoint imagine a better acceptance of a protocol running in an environment of thousands of network elements. But the way to reach this needs a kind of version management!

The way to reach acceptance is by a tightly written spec and
rigorous testing.

The spec already uses TLVs, that should be sufficient as long
as it doesn't reuse type values.

Adding a version mechanism adds complexity, and can lead to
future interoperability issues.

Regards,
Steve Senum

> 
> Regards
> 
> Thomas 
> 
> -----Ursprüngliche Nachricht-----
> Von: Steve Senum (ssenum) [mailto:[email-masked]] 
> Gesendet: Freitag, 1. Dezember 2006 16:53
> An: Busser, Michael
> Cc: [email-masked]
> Betreff: RE: [ANCP] Protocol version nummer for ANCP
> 
> Hi,
> 
> This should be avoided if at all possible.
> 
> You are adding complexity into the protocol and
> implementations to deal with issues between drafts,
> which will need to be carried forwarded when this
> becomes a RFC.  I have not seen an Internet Area
> Director support this in past instances.  You can't
> even reference an internet-draft in an RFC.
> 
> The other ways I have seen this dealt with in the past,
> somewhat in order of preference:
> 
> 1. Clean cutover approach, all system roll to a new
>    version.
> 
> 2. Add checks in the code to deal with known cases.
> 
> 3. Add a version setting to the config to handle this.
> 
> Regards,
> Steve Senum
> 
> >  
> > 
> > -----Original Message-----
> > From: Busser, M [mailto:[email-masked]] 
> > Sent: Friday, December 01, 2006 6:19 AM
> > To: [email-masked]
> > Subject: [ANCP] Protocol version nummer for ANCP
> > 
> > Hi all.
> > 
> >  
> >  Problem:
> >  Currently different codes exist referring to 
> >    draft-wadhwa-gsmp-l2control-configuration-00 & 
> >    draft-wadhwa-gsmp-l2control-configuration-02.
> >  
> >  The lack of having different codes in different network elements is
> to
> >  create a situation of non interoperable TLV because TLV changed (e.g.
> > 90/91)
> >  
> >  Solution:
> >  The only way out is to define a protocol version field in combination
> >  with a software management in the network element:
> >  
> >  A proposal is shown below:
> >  
> >  We should have a format like <main.sub> version number, where main as
> >  well as sub is represented by a 1 byte value. 
> >  We should start with 0.1 representing
> > draft-wadhwa-gsmp-l2control-configuration-02.
> >  
> >  Procedures
> >  Add a new Capability:  Version Length=4
> >  					Byte 0 = Main Version Nr of
> > oldest supported protocol version
> >  					Byte 1 = Sub Version  Nr of
> > oldest supported protocol version
> >  					Byte 2 = Main Version Nr of
> > latest supported protocol version
> >  					Byte 3 = Sub Version  Nr of
> > latest supported protocol version
> >  
> >  If only one specific version is supported by a network element, the 
> >  oldest and the latest version number are the same.
> >  
> >  Requirement:
> >  
> >  To define a protocol version TLV first before enhancing 
> >  draft-wadhwa-gsmp-l2control-configuration-02 in further steps.
> >  
> >   
> >  
> >  Best regards
> >  
> >  Thomas & Michael
> > 
> > _______________________________________________
> > 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: "Peter Arberg" <[email-masked]>
Date: Sun, 3 Dec 2006 00:51:26 +0100

Hi,

I agree that the version control is a functionality we need 
to add to the ANCP protocol.

But I do not think we have to ADD it, I just think we have to
start using it, as we alreday have a version.sub-version field 
in the GSMP header, so I will suggest we decide to use this 
for the ANCP usage as well.

We could say ANCP is not backward compatible with GSMP, 
but are defining all GSMP related informations we are using, 
and as such we could reuse the GSMP version and subversion 
number as a ANCP version control instead of keeping this on 3.1.

So a decision to increase this version number starting with draft-2
will make sure that the attribute changes are recorded, and we
have a version number which clearly will show that we are using
ANCP functionality, and not GSMP 3.1 defined functionality.

cheers,
Peter 

> From: Steve Senum (ssenum) [mailto:[email-masked]] 
> Sent: 2. december 2006 00:01
> To: Haag, T
> Cc: Hamacher, Peter; [email-masked]
> Subject: RE: [ANCP] Protocol version nummer for ANCP
> 
> Hi Thomas,
> 
> > Best practice to get running a new protocol is to implement 
> first code check and improve it. But to manage the 
> improvement a version negotiation can not be avoided because 
> of already existing code which is not only present in a laboratory. 
> > 
> > To set all systems in the field to a new code seems a 
> little bit different to update thousands of access nodes and 
> related BNGs at the same time. I've never seen this running 
> outside in the field. 
> > 
> > Again, I highly recommend thinking about. May be in the 
> past this was not accepted, but the future is now. From a 
> operator standpoint the business is too fast to wait until a 
> draft has become a RFC is finalized. 
> 
> > You can not from a vendor standpoint imagine a better 
> acceptance of a protocol running in an environment of 
> thousands of network elements. But the way to reach this 
> needs a kind of version management!
>

---

From: "Kim Hyldgaard \(ST/LMD\)" <[email-masked]>
Date: Mon, 4 Dec 2006 07:22:18 +0100

Hi,

I agree with Peter on this matter.

Version control is needed even though we're still at the draft
stage, however I'd also appreciate a simple approach.

Is there a risk that we'll run into problems later if
we use the version field from GSMP directly?

If "We could say ANCP is not backward compatible with GSMP,
but are defining all GSMP related informations we are using"
is a valid statement, it should be OK to use the GSMP version field.

Br
Kim

-----Original Message-----
From: Peter Arberg [mailto:[email-masked]] 
Sent: 3. december 2006 00:51
To: 'Steve Senum (ssenum)'; 'Haag, T'
Cc: 'Hamacher, Peter'; [email-masked]
Subject: RE: [ANCP] Protocol version nummer for ANCP

Hi,

I agree that the version control is a functionality we need to add to the ANCP protocol.

But I do not think we have to ADD it, I just think we have to start using it, as we alreday have a version.sub-version field in the GSMP header, so I will suggest we decide to use this for the ANCP usage as well.

We could say ANCP is not backward compatible with GSMP, but are defining all GSMP related informations we are using, and as such we could reuse the GSMP version and subversion number as a ANCP version control instead of keeping this on 3.1.

So a decision to increase this version number starting with draft-2 will make sure that the attribute changes are recorded, and we have a version number which clearly will show that we are using ANCP functionality, and not GSMP 3.1 defined functionality.

cheers,
Peter 

> first code check and improve it. But to manage the improvement a 
> version negotiation can not be avoided because of already existing 
> code which is not only present in a laboratory.
> > 
> little bit different to update thousands of access nodes and related 
> BNGs at the same time. I've never seen this running outside in the 
> field.
> > 
> past this was not accepted, but the future is now. From a operator 
> standpoint the business is too fast to wait until a draft has become a 
> RFC is finalized.
> 
> acceptance of a protocol running in an environment of thousands of 
> network elements. But the way to reach this needs a kind of version 
> management!
> 
> The way to reach acceptance is by a tightly written spec and rigorous 
> testing.
> 
> The spec already uses TLVs, that should be sufficient as long as it 
> doesn't reuse type values.
> 
> Adding a version mechanism adds complexity, and can lead to future 
> interoperability issues.
> 
> Regards,
> Steve Senum
> 
> > 
> > Regards
> > 
> > Thomas
> > 
> > You are adding complexity into the protocol and implementations to 
> > deal with issues between drafts, which will need to be carried 
> > forwarded when this becomes a RFC.  I have not seen an Internet Area 
> > Director support this in past instances.  You can't even reference 
> > an internet-draft in an RFC.
> > 
> > The other ways I have seen this dealt with in the past, somewhat in 
> > order of preference:
> >

---

From: Jakob Heitz <[email-masked]>
Date: Sun, 03 Dec 2006 22:52:57 -0800

To add to this position:
A new protocol version should be a rare requirement.
We can add new TLVs without having to increment the
protocol version.
We can even change a TLV without incrementing the
protocol version. We can change a TLV, by using
a new type number for the changed TLV. That would
not require a new protocol version.

The only thing that would require a new protocol
version is changes to the protocol itself, ie.
how the protocol works.
An example of such a change would be a multi timer
keepalive: Slow keepalive timer until we miss one.
After a keepalive is lost, switch to a quick timer.
If an ack is received, switch back to the slow timer.
Such a change would require a new protocol version.

Regards,
Jakob Heitz