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

From: "Steve Senum \(ssenum\)" <[email-masked]>
Date: Fri, 1 Dec 2006 10:52:50 -0500

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

---

From: "Haag, T" <[email-masked]>
Date: Fri, 1 Dec 2006 21:54:09 +0100

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. 

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!

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,

Regards,
Steve Senum

to