Re: [sfc] Additional AD review comments on draft-ietf-sfc-nsh-20

["Carlos Pignataro (cpignata)" <[e-mail]>]

Hi, Alia,

You addressed this email to me, but I just noticed I failed to respond — apologies!

> On Sep 7, 2017, at 3:39 PM, Alia Atlas <[e-mail]> wrote:
> 
> Carlos,
> 
> The draft is much improved.  Thank you for your hard work.  I still see the following three issues.
> 

Thanks, let’s see those three, inline.

> 
> 1) Sec 2.2: "The O bit MUST be set for OAM packets and MUST NOT be set for non-OAM
>    packets.  The O bit MUST NOT be modified along the SFP."
> What happens if the packet is reclassified - potentially to a different SFP?  
> 
> Sec 3 doesn't clarify this."When the logical classifier performs re-
>        classification that results in a change of service path, it MUST
>        replace the existing NSH with a new NSH with the Base Header and
>        Service Path Header reflecting the new service path information
>        and MUST set the initial SI.  Metadata MAY be preserved in the
>        new NSH."
> 

I do not think Sec 3 needs to clarify it. Section 2.2 already says:

“O bit: […] The actual format and processing of SFC
   OAM packets is outside the scope of this specification”

So we should not attempt to specify the processing here. 

If you believe it helps, we can add “The value of the O bit MUST be preserved in the new NSH”, but that would go against S2.2’s scope.

> It would be good to specify the behavior for the unassigned flags as well; that way there will be consistent assumptions for future extensions, if needed.
> 

Since they are Unassigned, the have no behavior specified, other than what’s already there:

“Unassigned bits MUST
   be set to zero upon origination, and MUST be ignored and preserved
   unmodified by other NSH supporting elements.  At reception, all
   elements MUST NOT modify their actions based on these unknown bits.”

What else is missing?

> 2) Sec 7.1: "For example, if the metadata conveys tenant information, that information may need to be authenticated and/or encrypted between the originator and the
>    intended recipients (which may include intended SFs only)."
> A reference to draft-reddy-sfc-nsh-encrypt, which defines how to encrypt the meta-data would be most helpful in making this sound less aspirational;

Sure. It’s already cited in the Security Considerations section, but we can add another citation. Done in the working copy.

> so would having that draft not be 2 years expired and ignored by the WG. 
> 
> 3) Sec 11.2.5: Guidance for the expert review is needed.

Good point. Thanks.

Here’s an attempt, please complete. I am hesitant to request discussion on the SFC list, do you think we should (and request in that document that the list is kept open)?

<t>
Expert Review requests MUST include a single code point per request.
   Designated Experts evaluating new allocation requests from this registry
   should consider the potential scarcity of code points for an 8-bit value,
   and check both for duplications as well as availability of documentation.
</t>



> 
> Regards,
> Alia

—
Carlos Pignataro, [e-mail]

“Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis."