Subject: [sfc] Alexey Melnikov's No Objection on draft-ietf-sfc-nsh-24: (with COMMENT)

From: Alexey Melnikov <[email-masked]>
Date: Wed, 27 Sep 2017 02:29:53 -0700

Alexey Melnikov has entered the following ballot position for
draft-ietf-sfc-nsh-24: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I am agreeing with Kathleen's DISCUSS.

Also, have you thought about likelyhood of introducing new versions, and if it
is likely, what kind of restrictions do you want to impose on future versions
(e.g. requirements on backward compatibility) and what are the criteria for
bumping the version number? For example, future versions must use the same Base
Header and Service Path header, but can add new mandatory fields after that.
Etc.

---

From: <[email-masked]>
Date: Wed, 27 Sep 2017 11:49:42 +0000

Dear Alexey, 

With regards to your comment about future versions, the WG used to have this ticket: https://trac.ietf.org/trac/sfc/ticket/6 

There wasn't a consensus to add version negotiation or to discuss how backward compatibility will be ensured. 

There was a suggestion by Joel at that time to include this NEW text (https://www.ietf.org/mail-archive/web/sfc/current/msg03181.html): 

"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."

Paul (one the document editors) agreed with that text but I'm afraid that text wasn't added to the draft. It isn't too late, though.

Thank you.

Cheers,
Med

> -----Message d'origine-----
> De : sfc [mailto:[email-masked]] De la part de Alexey Melnikov
> Envoyé : mercredi 27 septembre 2017 11:30
> À : The IESG
> Cc : [email-masked]; [email-masked]; sfc-
> [email-masked]; [email-masked]
> Objet : [sfc] Alexey Melnikov's No Objection on draft-ietf-sfc-nsh-24:
> (with COMMENT)
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 27 Sep 2017 12:02:27 +0000

Thank, Alexey.

> On Sep 27, 2017, at 5:29 AM, Alexey Melnikov <[email-masked]> wrote:
> 

This is a good question.

The WG did not deeply consider what the requirements might be to have to version++. Frankly, we were all focused on getting this version right :-) which would minimize the need for bumping up the version field.

The Version field is there to ensure interoperability — so a non-interoperable change to NSH might require increasing the version field, and defining within the new version the potential backwards compatibility modes. But, again, seems wildly premature to attempt to foresee what those might be, if any. Personally, I think need not be too prescriptive on this.

A separate (yet related) question is what Med brought up, which is the treatment of other (potentially future) versions by the current spec. That is indeed something we need to specify.

I’ll add the text from Joel H. that Med pointed to. (Thanks Med! And Joel!)

	"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."

Alexei, WG, please let us know if there’s any concerns with this approach.

Thanks!

Carlos.