Subject: [sfc] Removing C (critical) flag from draft-ietf-sfc-nsh

From: Dave Dolson <[email-masked]>
Date: Wed, 18 Jan 2017 20:55:08 +0000

At the SFC interim meeting today, there seems to be support for:
- removing the "C" flag from the NSH base header, returning the bit to "reserved" status (section 3.2)
- removing the "C" flag from the variable-length metadata header, making the Type an 8-bit field. (section 3.5.1)
- and removing all of the wording about "critical metadata"

The rationale: it seems that it would only be valid to set the C-flag if every single SFC component understands the critical metadata being used (otherwise packet will be dropped). However, if every component understands the critical metadata there is no need for the C-flag. So it seems the C-flag merely serves to complicate the protocol.
This question came up while trying to understand how to handle unknown MD-Types when the C-flag is set.

I was asked to send this question to the mailing list to see if there are objections to removing the C-flag.

-Dave

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 18 Jan 2017 21:12:45 -0000

Thanks Dave,
 
That captures what I heard and agrees with what I think.
 
I would note that there is the possibility of a TLV that an implementation
understands but can choose to ignore or process, and the C flag would override
this choice forcing it to process. However, I do not have a use case for this
and I don't think we should specify a speculative protocol feature.
 
Adrian
--
Support an author and your imagination.
Tales from the Wood - Eighteen new fairy tales.
More Tales from the Wood - Eighteen MORE new fairy tales.
https://www.feedaread.com/profiles/8604/
http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924
Or buy from me direct.

From: sfc [mailto:[email-masked]] On Behalf Of Dave Dolson
Sent: 18 January 2017 20:55
To: [email-masked]
Cc: Elzur, Uri; Paul Quinn (paulq)
Subject: [sfc] Removing C (critical) flag from draft-ietf-sfc-nsh
 
At the SFC interim meeting today, there seems to be support for:
- removing the "C" flag from the NSH base header, returning the bit to
"reserved" status (section 3.2)
- removing the "C" flag from the variable-length metadata header, making the
Type an 8-bit field. (section 3.5.1)
- and removing all of the wording about "critical metadata"
 
The rationale: it seems that it would only be valid to set the C-flag if every
single SFC component understands the critical metadata being used (otherwise
packet will be dropped). However, if every component understands the critical
metadata there is no need for the C-flag. So it seems the C-flag merely serves
to complicate the protocol.
This question came up while trying to understand how to handle unknown MD-Types
when the C-flag is set.
 
I was asked to send this question to the mailing list to see if there are
objections to removing the C-flag.
 
-Dave