Subject: [sfc] draft-quinn-sfc-nsh: version number

From: <[email-masked]>
Date: Wed, 25 Feb 2015 15:03:35 +0000

Hi Paul, all,

What is the purpose of having a version number in the header? Is there a kind of version negotiation that needs to be in place?

I checked the I-D but failed to find text that explains the rationale, the use of the such field and whether an error will be returned if the version is not supported by the receiving node.

Wouldn't be preferable to get rid of this field given that SFC header can be extended using optional objects and consistent setup & configuration within an SFC-enabled domain should be assumed?

Thank you

Cheers,
Med

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 25 Feb 2015 10:09:43 -0500

I would really prefer to keep the version number.  Even though we have 
the MD-type identifier and for some MD we have the TLVs.

The reason is that we may want to change the base header.  For example, 
suppose that the ciscussion about including a flow identifier in the 
base header had not come up now.  If it came up later, we would want to 
be able to have the discussion and make the choice, rather than being 
constrained by the lack of a version field.

Yours,
Joel

On 2/25/15 10:03 AM, [email-masked] wrote:
> Hi Paul, all,
>
> What is the purpose of having a version number in the header? Is there a
> kind of version negotiation that needs to be in place?
>
> I checked the I-D but failed to find text that explains the rationale,
> the use of the such field and whether an error will be returned if the
> version is not supported by the receiving node.
>
> Wouldn’t be preferable to get rid of this field given that SFC header
> can be extended using optional objects and consistent setup &
> configuration within an SFC-enabled domain should be assumed?
>
> Thank you
>
> Cheers,
>
> Med
>
>
>
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: Ron Parker <[email-masked]>
Date: Wed, 25 Feb 2015 17:53:12 +0000

Joel,

I agree that version is valuable, dinstinctly from the MD-type.   While you could overload MD-type (i.e., for some new base flavor we have MD-types 3 and 4 corresponding to the old 1 and 2), this would be far less elegant and make the implementations somewhat trickier.

   Ron

-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Wednesday, February 25, 2015 10:10 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [sfc] draft-quinn-sfc-nsh: version number

I would really prefer to keep the version number.  Even though we have the MD-type identifier and for some MD we have the TLVs.

The reason is that we may want to change the base header.  For example, suppose that the ciscussion about including a flow identifier in the base header had not come up now.  If it came up later, we would want to be able to have the discussion and make the choice, rather than being constrained by the lack of a version field.

Yours,
Joel

On 2/25/15 10:03 AM, [email-masked] wrote:
> Hi Paul, all,
>
> What is the purpose of having a version number in the header? Is there 
> a kind of version negotiation that needs to be in place?
>
> Wouldn't be preferable to get rid of this field given that SFC header

---

From: <[email-masked]>
Date: Thu, 26 Feb 2015 07:16:16 +0000

Hi Joel,

I fully agree with the extendibility of the header, but the question is why having a version number will be of help in the context of SFC? Second, having a version number without specifying the behavior when several versions are supported, when the version number is not supported by an SFC-aware element, etc. leaves open issues out of the spec. 

The other problem is that the current I-D includes several open doors left for extending the header:
* version
* reserved bits
* optional data

This is too much for a header that is supposed to be compact and simple!

There are other means to extend the header without signaling the version in the packet. Having a distinct RFC number may be just fine in the context of an unidirectional stream such as SFC. 

Let us consider the situation where a version number is not explicitly signaled in the packet (but a new RFC updates the base SFC header). Several options can be considered, indeed (those are provided as examples for illustration purposes): 
* An operator can make sure that its SFC-enabled domain is configured in a consistent manner to support one and only one version of the header. No interoperability issues is encountered in this case.
* An operator that wants to upgrade its SFC-enabled domain to support a new specification of the SFC header: An operator can decide to proceed to a software/hardware updates but can maintain the old header in operation until all involved elements are upgraded to support the new version. Once the SFC-enabled domain is upgraded, then the new header can be enabled. 

Let's consider now that a version is signaled in the packet: to what extent signaling this information simplifies the SFC operations, and whether it increases/decreases the serviceability of an SFC-enabled domain? Let's also assess to what extent having the version number add more complexity in the SFC header treatment when several versions are supported by a node/within an SFC enabled domain? How it helps interoperability? Some points for discussion are elaborated below:

* If the SFC-enabled domain is configured to support the same version (which is likely): having the version number is not of any help.
* If the SFC-enabled domain involves some nodes that support version (v1) while others support (v2) (simple case): If these version are not backward compatible, this will lead to failures when two adjacent elements in a service chain do not support the same version. The SFC system is broken. Having the version number is not of any help in this case.
* If the SFC-enabled domain involves some nodes that support version (v1) while others support (v1 and v2): 

(a) The nodes that support both v1 and v2 should be instructed to decide which version to be used. This can be either part of the specification or be driven by configuration. If a version number is included in the spec, I would expect to clarify the behavior in such case.

(b) Suppose a node that supports only v1 receives a packet with header (v2): If this node does not support a notification procedure to inform the source that it does not support that header version, then FAILURES are introduced in the network. This is a degradation of the service compared to legacy scheme to structure services. This is not recommended, IMHO.

(c) If a notification is received from an element about its supported version: a node can use another version (the logic to select other version is another point to discuss) for that communication, but what to do for the next flows in the context of the same service chain or other chains that involves these two nodes as adjacent elements in the same chain? Shouldn't these nodes cache the version to use for subsequent exchange to avoid receiving the notification error each time? Wouldn't that complexity the behavior of the SFC-aware elements?

(d) If a notification is received from an element about its supported version: As this may occurs in various segments of a given service chain, e.g., (A(v1), B(v1,v2), C(v2), D(v1,v2), E(v1)). Notifying the adjacent node each time there is a version mismatch induce an extra delay, that may be not be acceptable for every flow.
  
I hope this clarifies my initial concern.

Thank you.

Cheers,
Med

> -----Message d'origine-----
> De : Joel M. Halpern [mailto:[email-masked]]
> Envoyé : mercredi 25 février 2015 16:10
> À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
> Cc : [email-masked]
> Objet : Re: [sfc] draft-quinn-sfc-nsh: version number
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 26 Feb 2015 09:24:26 -0500

In one sense you are correct.  If you could count on everything being 
upgraded at once, sure you could just assume common interpretation.
However, we have found over the years that such simultaneous upgrading 
never works.  You need to be able to transition.

I do agree that we should add text about what to do with version numbers 
that are not understood.  There are multiple choices that affect how we 
can make changes.  My personal preference is:

If an packet presumed to carry an NSH header is received at an SFF, and 
the SFF does not understnad the version of the protocol as indicated in 
the base header, the packet MUST be discarded, and the event SHOULD be 
logged.

This would allow an orderly transition, where devices can be upgraded to 
understand a new version, then generation of the new version header can 
be enabled.  If a configuration error is made, the packets will be 
dropped and operators following good practices will get notifications.

Yours,
Joel

---

From: <[email-masked]>
Date: Thu, 26 Feb 2015 14:43:39 +0000

Hi Joel,

mmm... an "operator following good practices" won't put into production a node that does not support a version that is not backward compatible with other nodes within an SFC enabled domain; worse, if your proposed behavior is followed, service chains involving that node will be broken ! 

IMHO, the points raised in my initial message are still open.

Cheers,
Med

> Envoyé : jeudi 26 février 2015 15:24
> > I fully agree with the extendibility of the header, but the question is
> why having a version number will be of help in the context of SFC? Second,
> having a version number without specifying the behavior when several
> versions are supported, when the version number is not supported by an
> SFC-aware element, etc. leaves open issues out of the spec.
> >
> > There are other means to extend the header without signaling the version
> in the packet. Having a distinct RFC number may be just fine in the
> context of an unidirectional stream such as SFC.
> >
> > Let us consider the situation where a version number is not explicitly
> signaled in the packet (but a new RFC updates the base SFC header).
> Several options can be considered, indeed (those are provided as examples
> for illustration purposes):
> > * An operator can make sure that its SFC-enabled domain is configured in
> a consistent manner to support one and only one version of the header. No
> interoperability issues is encountered in this case.
> > * An operator that wants to upgrade its SFC-enabled domain to support a
> new specification of the SFC header: An operator can decide to proceed to
> a software/hardware updates but can maintain the old header in operation
> until all involved elements are upgraded to support the new version. Once
> the SFC-enabled domain is upgraded, then the new header can be enabled.
> >
> > Let's consider now that a version is signaled in the packet: to what
> extent signaling this information simplifies the SFC operations, and
> whether it increases/decreases the serviceability of an SFC-enabled
> domain? Let's also assess to what extent having the version number add
> more complexity in the SFC header treatment when several versions are
> supported by a node/within an SFC enabled domain? How it helps
> interoperability? Some points for discussion are elaborated below:
> >
> > * If the SFC-enabled domain is configured to support the same version
> (which is likely): having the version number is not of any help.
> > * If the SFC-enabled domain involves some nodes that support version
> (v1) while others support (v2) (simple case): If these version are not
> backward compatible, this will lead to failures when two adjacent elements
> in a service chain do not support the same version. The SFC system is
> broken. Having the version number is not of any help in this case.
> > (a) The nodes that support both v1 and v2 should be instructed to decide
> which version to be used. This can be either part of the specification or
> be driven by configuration. If a version number is included in the spec, I
> would expect to clarify the behavior in such case.
> >
> > (b) Suppose a node that supports only v1 receives a packet with header
> (v2): If this node does not support a notification procedure to inform the
> source that it does not support that header version, then FAILURES are
> introduced in the network. This is a degradation of the service compared
> to legacy scheme to structure services. This is not recommended, IMHO.
> >
> > (c) If a notification is received from an element about its supported
> version: a node can use another version (the logic to select other version
> is another point to discuss) for that communication, but what to do for
> the next flows in the context of the same service chain or other chains
> that involves these two nodes as adjacent elements in the same chain?
> Shouldn't these nodes cache the version to use for subsequent exchange to
> avoid receiving the notification error each time? Wouldn't that complexity
> the behavior of the SFC-aware elements?
> >
> > (d) If a notification is received from an element about its supported
> version: As this may occurs in various segments of a given service chain,
> e.g., (A(v1), B(v1,v2), C(v2), D(v1,v2), E(v1)). Notifying the adjacent
> node each time there is a version mismatch induce an extra delay, that may
> be not be acceptable for every flow.
> >
> a

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 26 Feb 2015 09:50:33 -0500

Obviously, if the header never changes, the version number is indeed 
wasted bits.
However, I tend to perefer to design assuming that we have not made all 
the right calls, and will need to make changes in the future.

If an operator has running SFC insfrastructure, and we make introduce a 
new version, then by definition the operator, still following good 
practices, will have devices in his network that do not support the new 
header.  He will have to upgrade.  He will try to upgrade cleanly.  But:
1) Even if he gets all the upgrades done well, he needs a way to turn on 
the new features cleanly.  Since reconfiguring all devices at the same 
time is a non-starter, the devices will need to be able to tell new from 
old.
2) Operators have to allow for operational error.  It may be that not 
all the devices have gotten upgraded, even if the process he uses should 
have resulted in that.  We have all seen things go wrong in practice. 
So a version number field serves as an error check against these sorts 
of problems.

Thus, on the one hand version numbering allows for migration, and on the 
other hand it enables robust operation.  Seems like a very good trade.

Yours,
Joel

On 2/26/15 9:43 AM, [email-masked] wrote:
>> (v1) while others support (v1 and v2):
>>>

---

From: <[email-masked]>
Date: Thu, 26 Feb 2015 15:08:23 +0000

Re-,

Please see inline.

Cheers,
Med

> Envoyé : jeudi 26 février 2015 15:51
> À : BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; [email-masked]
> Cc : [email-masked]

[Med] There are various means to make changes. The current spec includes too many:
* optional elements
* reserved bits
* version
* MD type

Is this really justified for a header that is supposed to be compact (avoid fragmentation as much as possible)? Having the version number is not the only way to extend the header. 

> time is a non-starter, the devices will need to be able to tell new from

[Med] co-existence of both versions of the header are likely during transition period. Disrupting the service should be avoided. If this can be managed by the protocol, this will be optimal. If not, the operator should be prepared to make an action plan to coordinate the migration steps. 

> So a version number field serves as an error check against these sorts

[Med] This is exactly the same situation when no version is signaled in the packet but the node does not support the new RFC that updates the header. A node that receives a packet destined to it (as indicated at the transport encapsulation level) but cannot parse the header will log a failure.

> 
> Thus, on the one hand version numbering allows for migration,

[Med] How is that unique to version numbering ? I see a value in version numbering if it is used by the protocol to maintain the serviceability of a network. 

 and on the
> other hand it enables robust operation.

[Med] What is that mean?

  Seems like a very good trade.
> > mmm... an "operator following good practices" won't put into production
> a node that does not support a version that is not backward compatible
> with other nodes within an SFC enabled domain; worse, if your proposed
> behavior is followed, service chains involving that node will be broken !
> >