Subject: [ANCP] Protocol version nummer for ANCP

From: "Busser, M" <[email-masked]>
Date: Fri, 1 Dec 2006 13:19:13 +0100

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

---

From: Jakob Heitz <[email-masked]>
Date: Fri, 01 Dec 2006 09:15:37 -0800

The first byte of every message is Vers.Sub.
Use of this is a much simpler solution to this problem.
KISS

-- 
Jakob Heitz

---

From: Stefaan De Cnodder <[email-masked]>
Date: Mon, 04 Dec 2006 12:37:18 +0100

Indeed, making use of the version in the header is much simpler, and is 
something that is already there, no need to invent something new.  But 
the version/subversion number should not be incremented with every new 
version of the draft.... How would this then being handled?  A draft and 
later an RFC per version?  I hope this is not what we intend to do.... 
if you have a lot of versions it will be harder to find a BRAS and a 
DSLAM that supports the same version.

regards,
Stefaan

Jakob Heitz wrote:

>>  well as sub is represented by a 1 byte value.  We should start with 
>> 0.1 representing

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 04 Dec 2006 08:00:56 -0800

No problem. GSMP defines version negotiation:
         In the adjacency protocol the Version field is used for version
         negotiation.  The version negotiation is performed before
         synchronisation is achieved.  In a SYN message the Version
         field always contains the highest version understood by the
         sender.  A receiver receiving a SYN message with a version
         higher than understood will ignore that message.  A receiver
         receiving a SYN message with a version lower than its own
         highest version, but a version that it understands, will reply
         with a SYNACK with the version from the received SYN in its
         GSMP Version field.  This defines the version of the GSMP
         protocol to be used while the adjacency protocol remains
         synchronised.  All other messages will use the agreed version
         in the Version field.

Every time the draft changes in a way that would cause
errors if used with a previous draft, then the vers/sub
should be incremented.

Regards,
Jakob Heitz.

Stefaan De Cnodder wrote:
>
> Indeed, making use of the version in the header is much simpler, and 
> is something that is already there, no need to invent something new.  
> But the version/subversion number should not be incremented with every 
> new version of the draft.... How would this then being handled?  A 
> draft and later an RFC per version?  I hope this is not what we intend 
> to do.... if you have a lot of versions it will be harder to find a 
> BRAS and a DSLAM that supports the same version.
>
> regards,
> Stefaan
>
> Jakob Heitz wrote:
>

-- 
Jakob Heitz. x5475. 510-566-2901

---

From: Stefaan De Cnodder <[email-masked]>
Date: Tue, 05 Dec 2006 09:53:05 +0100

Hi Jakob,

> errors if used with a previous draft, then the vers/sub

Do you also mean that the IETF has to standardize all these versions in 
one or more RFCs?

regards,
Stefaan

---

From: "Peter Arberg" <[email-masked]>
Date: Tue, 5 Dec 2006 08:44:37 -0800

Hi Steefan,

I would not expect IETF to standardize all possible version
numbers in more than one RFC. I would expect the process with 
the draft to evolve to the RFC, and the version number in the 
last draft is the version number in the RFC defining ANCP, but
at the same time the RFC should define the differences between
new version numbers.

So for example, let us say we increase version number to 4.0
for the draft 2, then a small section outlining the changes
that required this version number increase would be required.

We do not expect version number change with every draft, it will
be, as Jakob said, a rare event and only needed if there is no
other way of interoperability between systems implementing a new
and an old draft.

The problem with ANCP is we started the IETF process after several
vendors have running code in production, and as such we need a 
way to make sure carriers can continue to run these networks
while vendors improve their ANCP implementation.

The version number is in my mind the best option to accomplish this,
even if it means we will use a couple of numbers on our way to
standardize the ANCP protocol.

cheers,
Peter

> -----Original Message-----
> From: Stefaan De Cnodder 
> [mailto:[email-masked]] 
> Sent: 5. december 2006 00:53
> To: Jakob Heitz
> Cc: [email-masked]
> Subject: Re: [ANCP] Protocol version nummer for ANCP
> 
> 
> Hi Jakob,
> 
> >