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

From: Sunil Vallamkonda <[email-masked]>
Date: Tue, 3 Mar 2015 19:43:17 +0000

Hi,

Just going through the thread on version number (jumping in mid-thread),

Apart from the version mismatched (unsupported) packet dropped and logged, is there a plan for a back off mechanism by SFF to notify sender and avoid being overwhelmed with such packets ?

Thank you,
Sunil.

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

  *   From: "Paul Quinn (paulq)" <paulq at cisco.com<mailto:[email-masked]>>
  *   To: "Joel M. Halpern" <jmh at joelhalpern.com<mailto:[email-masked]>>
  *   Cc: "mohamed.boucadair at orange.com<mailto:[email-masked]>" <mohamed.boucadair at orange.com<mailto:[email-masked]>>, "sfc at ietf.org<mailto:[email-masked]>" <sfc at ietf.org<mailto:[email-masked]>>
  *   Date: Mon, 2 Mar 2015 17:50:53 +0000
  *   In-reply-to: <[email-masked]<http://www.ietf.org/mail-archive/web/sfc/current/msg03181.html>>
  *   References: <[email-masked]> <[email-masked]<http://www.ietf.org/mail-archive/web/sfc/current/msg03151.html>> <[email-masked]> <[email-masked]<http://www.ietf.org/mail-archive/web/sfc/current/msg03181.html>>
  *   List-id: Network Service Chaining <sfc.ietf.org>

________________________________

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 <jmh at joelhalpern.com> 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, mohamed.boucadair at orange.com 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:jmh at joelhalpern.com]

>>> Envoyé : mercredi 25 février 2015 16:10

>>> À : BOUCADAIR Mohamed IMT/OLN; paulq at cisco.com

>>> Cc : sfc at ietf.org

>>> 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, mohamed.boucadair at orange.com 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

>>>> sfc at ietf.org

>>>> https://www.ietf.org/mailman/listinfo/sfc

---

From: <[email-masked]>
Date: Wed, 4 Mar 2015 06:46:37 +0000

Hi Sunil,

There is no such notification in the current spec.

Below my thoughts about this point:

==

(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(v1), 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.
==

Thank you.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Sunil Vallamkonda
Envoyé : mardi 3 mars 2015 20:43
À : [email-masked]
Objet : Re: [sfc] draft-quinn-sfc-nsh: version number

Hi,

Thank you,
Sunil.

  *   References: <[email-masked]<mailto:[email-masked]>> <[email-masked]<http://www.ietf.org/mail-archive/web/sfc/current/msg03151.html>> <[email-masked]<mailto:[email-masked]>> <[email-masked]<http://www.ietf.org/mail-archive/web/sfc/current/msg03181.html>>

Hi,

Jumping in mid-thread.

Paul

---

From: Ron Parker <[email-masked]>
Date: Wed, 4 Mar 2015 15:02:46 +0000

When we take up OAM, we could consider these ICMP-like behaviors - i.e., OAM packet containing "Version Incompatible" sent in the reverse direction on the involved RSP.   But I'm not sure what should be discussed in this draft, since OAM is explicitly out of scope.

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, March 4, 2015 1:47 AM
To: Sunil Vallamkonda
Cc: [email-masked]
Subject: Re: [sfc] draft-quinn-sfc-nsh: version number

Hi Sunil,

==

Thank you.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de Sunil Vallamkonda
Envoyé : mardi 3 mars 2015 20:43
À : [email-masked]<mailto:[email-masked]>
Objet : Re: [sfc] draft-quinn-sfc-nsh: version number

Hi,

Thank you,
Sunil.

Hi,

Jumping in mid-thread.

Paul

---

From: <[email-masked]>
Date: Wed, 4 Mar 2015 15:42:39 +0000

Hi Ron,

If the version number is maintained, discussing the behavior of a node if it supports several versions, if it does not support the version of a packet it receives, etc. is not about OAM. This is part of the behavior that needs to be specified in the document.

Cheers,
Med

De : Ron Parker [mailto:[email-masked]]
Envoyé : mercredi 4 mars 2015 16:03
À : BOUCADAIR Mohamed IMT/OLN; Sunil Vallamkonda
Cc : [email-masked]
Objet : RE: Re: [sfc] draft-quinn-sfc-nsh: version number

   Ron

From: sfc [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Wednesday, March 4, 2015 1:47 AM
To: Sunil Vallamkonda
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] draft-quinn-sfc-nsh: version number

Hi Sunil,

==

Thank you.

Cheers,
Med

Hi,

Thank you,
Sunil.

Hi,

Jumping in mid-thread.

Paul

---

From: Ron Parker <[email-masked]>
Date: Wed, 4 Mar 2015 15:50:09 +0000

Med,

I agree that we should add additional text around the expected behavior regarding version incompatibility.   We could state that the SFF or SF perceiving this incompatibility MUST drop such a packet and MAY generate an OAM response in the reverse direction, although the exact nature of that response is outside the scope of the NSH draft.

   Ron

From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, March 4, 2015 10:43 AM
To: Ron Parker; Sunil Vallamkonda
Cc: [email-masked]
Subject: RE: Re: [sfc] draft-quinn-sfc-nsh: version number

Hi Ron,

Cheers,
Med

Cc : [email-masked]<mailto:[email-masked]>

   Ron

Hi Sunil,

==

Thank you.

Cheers,
Med

Hi,

Thank you,
Sunil.

Hi,

Jumping in mid-thread.

Paul

---

From: <[email-masked]>
Date: Wed, 4 Mar 2015 16:09:41 +0000

Re-,

That would be a good start, but still not sufficient IMHO.

If no notification is sent back (which can be the case with the MAY language), the failure will be experienced till an action is done by the domain operator. This is not desirable.

Having a more strong language for sending back the response (that needs to include at least the received packet with the unsupported version) will have the effect to resend the packet with an adequate version (if multiple versions are supported). The exact behavior when a version mismatch error is received should be explicated in the document IMO.

Cheers,
Med

De : Ron Parker [mailto:[email-masked]]
Envoyé : mercredi 4 mars 2015 16:50
À : BOUCADAIR Mohamed IMT/OLN; Sunil Vallamkonda
Cc : [email-masked]
Objet : RE: Re: [sfc] draft-quinn-sfc-nsh: version number

Med,

   Ron

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]

Hi Ron,

Cheers,
Med

   Ron

Hi Sunil,

==

Thank you.

Cheers,
Med

Hi,

Thank you,
Sunil.

Hi,

Jumping in mid-thread.

Paul

---

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

On Mar 4, 2015, at 11:09 AM, [email-masked]<mailto:[email-masked]> wrote:

Re-,

Perhaps the best way forward: can you please suggest some text that we can all review?  I’m inclined to keep things simple (i.e. simple error message of sorts) but since you’ve given this a lot of thought, I’d love to see your suggestions.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 04 Mar 2015 14:54:41 -0500

Med, you seem to be assuming that misconfiguration MUST be addressed by 
immediate data plane response.
That is a major protocol requirement which is often counter-productive. 
  It is not at all clear that the ingress classifier would know what to 
do with such a notification any more than the device which does not 
understand the specific version.

It is extremely likely that repair will require human intervention.  It 
is also likely that management plane notifications will go to the same 
controller that set up the ingress instructions, so if there is feasible 
automatic response, the sytem can respond.

Requiring an in-band response to the classifier adds complication 
without significantly improving responsiveness.

Yours,
Joel

On 3/4/15 11:09 AM, [email-masked] wrote:
> If no notification is sent back (which can be the case with the MAY
> language), the failure will be experienced till an action is done by the
> domain operator. This is not desirable.
>
> Having a more strong language for sending back the response (that needs
> to include at least the received packet with the unsupported version)
> will have the effect to resend the packet with an adequate version (if
> multiple versions are supported). The exact behavior when a version
> mismatch error is received should be explicated in the document IMO.
>
> Cheers,
>
> Med
>
> *De :*Ron Parker [mailto:[email-masked]]
> *Envoyé :* mercredi 4 mars 2015 16:50
> *À :* BOUCADAIR Mohamed IMT/OLN; Sunil Vallamkonda
> *Cc :* [email-masked]
> *Objet :* RE: Re: [sfc] draft-quinn-sfc-nsh: version number
>
> Med,
>
> I agree that we should add additional text around the expected behavior
> regarding version incompatibility.   We could state that the SFF or SF
> perceiving this incompatibility MUST drop such a packet and MAY generate
> an OAM response in the reverse direction, although the exact nature of
> that response is outside the scope of the NSH draft.
>
>     Ron
>
> *From:[email-masked]
> <mailto:[email-masked]> [mailto:[email-masked]]
> *Sent:* Wednesday, March 4, 2015 10:43 AM
> *To:* Ron Parker; Sunil Vallamkonda
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* RE: Re: [sfc] draft-quinn-sfc-nsh: version number
>
> Hi Ron,
>
> If the version number is maintained, discussing the behavior of a node
> if it supports several versions, if it does not support the version of a
> packet it receives, etc. is not about OAM. This is part of the behavior
> that needs to be specified in the document.
>
> Cheers,
>
> Med
>
> *De :*Ron Parker [mailto:[email-masked]]
> *Envoyé :* mercredi 4 mars 2015 16:03
> *À :* BOUCADAIR Mohamed IMT/OLN; Sunil Vallamkonda
> *Cc :* [email-masked] <mailto:[email-masked]>
> *Objet :* RE: Re: [sfc] draft-quinn-sfc-nsh: version number
>
> When we take up OAM, we could consider these ICMP-like behaviors – i.e.,
> OAM packet containing “Version Incompatible” sent in the reverse
> direction on the involved RSP.   But I’m not sure what should be
> discussed in this draft, since OAM is explicitly out of scope.
>
>     Ron
>
> *From:*sfc [mailto:[email-masked]] *On Behalf Of
> [email-masked] <mailto:[email-masked]>
> *Sent:* Wednesday, March 4, 2015 1:47 AM
> *To:* Sunil Vallamkonda
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [sfc] draft-quinn-sfc-nsh: version number
>
> Hi Sunil,
>
> (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(v1), 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.
>
> ==
>
> Thank you.
>
> Cheers,
>
> Med
>
> *De :*sfc [mailto:[email-masked]] *De la part de* Sunil Vallamkonda
> *Envoyé :* mardi 3 mars 2015 20:43
> *À :* [email-masked] <mailto:[email-masked]>
> *Objet :* Re: [sfc] draft-quinn-sfc-nsh: version number
>
> Hi,
>
> Apart from the version mismatched (unsupported) packet dropped and
> logged, is there a plan for a back off mechanism by SFF to notify sender
> and avoid being overwhelmed with such packets ?
>
> Thank you,
>
> Sunil.
>
>
>   Re: [sfc] draft-quinn-sfc-nsh: version number**
>
> ------------------------------------------------------------------------
>
>   * /From/: "Paul Quinn (paulq)" <paulq at cisco.com
>     <mailto:[email-masked]>>
>   * /To/: "Joel M. Halpern" <jmh at joelhalpern.com
>     <mailto:[email-masked]>>
>   * /Cc/: "mohamed.boucadair at orange.com
>     <mailto:[email-masked]>" <mohamed.boucadair at
>     orange.com <mailto:[email-masked]>>, "sfc at
>     ietf.org <mailto:[email-masked]>" <sfc at ietf.org
>     <mailto:[email-masked]>>
>   * /Date/: Mon, 2 Mar 2015 17:50:53 +0000
>   * /In-reply-to/: <[email-masked]
>     <http://www.ietf.org/mail-archive/web/sfc/current/msg03181.html>>
>   * /References/:
>     <[email-masked]
>     <mailto:[email-masked]>>
>     <[email-masked]
>     <http://www.ietf.org/mail-archive/web/sfc/current/msg03151.html>>
>     <[email-masked]
>     <mailto:[email-masked]>>
>     <[email-masked]
>     <http://www.ietf.org/mail-archive/web/sfc/current/msg03181.html>>
>   * /List-id/: Network Service Chaining <sfc.ietf.org>
>
> ------------------------------------------------------------------------
>
> Hi,
>
>
>
> Jumping in mid-thread.
>
>
>
> I think Joel’s suggestion below makes perfect sense and should be added to the draft.
>
>
>
> Paul
>
>
>
>
>
> [email-masked]

---

From: <[email-masked]>
Date: Thu, 5 Mar 2015 06:46:43 +0000

Hi Paul,

Glad to see that we are sharing the same objective to design simple things, but the design should not cause another yet set of failure cases (which is the case of the current spec: the non-support of the MD type will be a cause of failure too).

I already provided a long message with my thoughts (http://www.ietf.org/mail-archive/web/sfc/current/msg03175.html).

I can propose text, but we need to agree first. I'm still questioning the need to have the version field in addition to other fields such as MD type.

I hope to see more feedback from the WG participants other than the authors of the draft so that I can adjust the proposed text.

Cheers,
Med

De : Paul Quinn (paulq) [mailto:[email-masked]]
Envoyé : mercredi 4 mars 2015 17:15
À : BOUCADAIR Mohamed IMT/OLN
Cc : Ron Parker; Sunil Vallamkonda; [email-masked]
Objet : Re: [sfc] draft-quinn-sfc-nsh: version number

Re-,

Perhaps the best way forward: can you please suggest some text that we can all review?  I'm inclined to keep things simple (i.e. simple error message of sorts) but since you've given this a lot of thought, I'd love to see your suggestions.

---

From: Ron Parker <[email-masked]>
Date: Thu, 5 Mar 2015 14:20:40 +0000

Med,

Albeit, from a co-author's perspective, the MD type, as I see it, is the current grand compromise, attempting to balance ease of parsing (MD type 1) and unconstrained flexibility (MD type 2).

   Ron

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, March 5, 2015 1:47 AM
To: Paul Quinn (paulq)
Cc: Ron Parker; Sunil Vallamkonda; [email-masked]
Subject: RE: [sfc] draft-quinn-sfc-nsh: version number

Hi Paul,

Cheers,
Med

Cc : Ron Parker; Sunil Vallamkonda; [email-masked]<mailto:[email-masked]>

Re-,

---

From: <[email-masked]>
Date: Fri, 6 Mar 2015 07:15:25 +0000

Hi Ron,

Thank you for this clarification.

I would buy the argument if inserting some contexts was mandatory, but this is not the case. Moreover, I don't understand from the draft what is the rationale for classifying the context into these four categories. What is meant by "platform-specific metadata" or "service platform specific"?

My personal point of view is that we need to choose. I'm personally for a minimalist header. Leaving both induces more complexity.

FWIW, this thread http://www.ietf.org/mail-archive/web/sfc/current/msg03150.html can be used for MD type related discussions.

Cheers,
Med

De : Ron Parker [mailto:[email-masked]]
Envoyé : jeudi 5 mars 2015 15:21
À : BOUCADAIR Mohamed IMT/OLN; Paul Quinn (paulq)
Cc : Sunil Vallamkonda; [email-masked]
Objet : RE: [sfc] draft-quinn-sfc-nsh: version number

Med,

   Ron

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Thursday, March 5, 2015 1:47 AM
To: Paul Quinn (paulq)
Cc: Ron Parker; Sunil Vallamkonda; [email-masked]<mailto:[email-masked]>
Subject: RE: [sfc] draft-quinn-sfc-nsh: version number

Hi Paul,

Cheers,
Med

Re-,