Subject: [sfc] draft-quinn-sfc-nsh: critical metadata

From: <[email-masked]>
Date: Wed, 25 Feb 2015 16:04:38 +0000

Hi Paul,

You are defining two codepoints for "critical" and "no critical" metadata.

This terminology is confusing given the "criticality" of a metadata is deployment-specific. An operator will make sure that involved elements are upgraded to support a given context information that is mandatory-to-support for his deployment.

Why you there will be mandatory-to-implement metadata? Shouldn't this be achieved by configuration locally to each SF-involved element?

Furthermore, the current text says:

   If a receiver receives an encapsulated packet containing a TLV with
   the Critical bit set in the Type field and it does not understand how
   to process the Type, it MUST drop the packet.  Transit devices MUST
   NOT drop packets based on the setting of this bit.

Dropping the packet without even sending a notification to the sender is too aggressive IMHO. Why such behavior is proposed in the draft? Wouldn't that behavior lead to more service degradation when SFC in enabled compared to current service deployment schemes?

Cheers,
Med