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

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Mon, 2 Mar 2015 17:50:53 +0000

Hi,

Jumping in mid-thread.  

Overall, I tend to agree with Joel.  Having an explicit version provides a simple way to handle dataplane format changes.  As Med points out, quickly correctly, IMHO, there are other way to signal changes via reserved bit.  In practice though reserved bits are less useful since the convention is to ignore unknown bits, it makes using them for feature changes quite difficult, which then brings up back to explicit versioning that cannot be ignored.  

I think Joel’s suggestion below makes perfect sense and should be added to the draft.

Paul

> On Feb 26, 2015, at 9:24 AM, Joel M. Halpern <[email-masked]> wrote:
> 
> 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
> 
> On 2/26/15 2:16 AM, [email-masked] wrote:
>> 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
>>> 
>>> 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: <[email-masked]>
Date: Wed, 4 Mar 2015 06:37:29 +0000

Hi Paul,

Issues related to co-existence and managing several versions of the header within a SFC-enabled domain won't disappear with aversion field. As I said in another message, many open doors are left in the current version of the draft for future extensions: version, optional elements, reserved bits, and MD type. This is not optimal for a header that is supposed to be compact as possible.

My initial concern is how to ensure the extendibility of the header while avoiding operational burden and avoid failures because of the header design choices. 

In addition to the issue related to the version number side effects, there also failures that will be induced by the non-support of MD Type (note, I'm not convinced yet MD type is needed)

Adding a sentence that says a packet will be dropped if the received node does not support that version is not sufficient. I listed several points in this thread that need to be addressed. 

Thank you.

Cheers,
Med 

> De : Paul Quinn (paulq) [mailto:[email-masked]]
> Envoyé : lundi 2 mars 2015 18:51
> À : Joel M. Halpern
> Cc : BOUCADAIR Mohamed IMT/OLN; [email-masked]
> Overall, I tend to agree with Joel.  Having an explicit version provides a
> simple way to handle dataplane format changes.  As Med points out, quickly
> correctly, IMHO, there are other way to signal changes via reserved bit.
> In practice though reserved bits are less useful since the convention is
> to ignore unknown bits, it makes using them for feature changes quite
> difficult, which then brings up back to explicit versioning that cannot be
> ignored.
> 
> I think Joel's suggestion below makes perfect sense and should be added to
> the draft.
> 
> Paul
> 
> 
> > 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
> >
> >> 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.
> >>

---

From: "Paul Quinn (paulq)" <[email-masked]>
Date: Wed, 4 Mar 2015 16:50:09 +0000

Hi Med,

I replied to a later email in the thread — my sorting was odd — but also wanted to give some comments here.

Paul

> On Mar 4, 2015, at 1:37 AM, [email-masked] wrote:
> 
> Hi Paul,
> 

I understand you concern, however, given how reserved bits are handled, they don’t provide the needed dataplane signaling.

> My initial concern is how to ensure the extendibility of the header while avoiding operational burden and avoid failures because of the header design choices. 

We share the same goal :) but I think the cost of a few version bit far outweighs the downside.   

> Adding a sentence that says a packet will be dropped if the received node does not support that version is not sufficient. I listed several points in this thread that need to be addressed. 

I don’t think a specific version field changes many of the points you list, in other words, if a protocol’s “features” change, you still need a method to ensure that the correct format is supported and backward compatibility is understood (to some extent).  If for example, we use a reserved bit _and_ mandate parsing of all reserved bits, in essence you just create a bigger version field.

>> (v1) while others support (v1 and v2):
>>>>