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

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

Hi Alia,

First, thanks for the follow-up and dialogue.

-23 is out.

I am now convinced that specifying the behavior regarding the O and unassigned bits upon reclassification is not only harmless, not only useful, but potentially necessary. Thanks for pushing.

The IANA comment about signaling when half empty / half full is good — if IANA signs up for it. But, like Joel, I am not sure how to write to “give preference” to standard protocols.

Thanks!

—
Carlos Pignataro, [e-mail]<mailto:[e-mail]>

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

On Sep 22, 2017, at 4:25 PM, Alia Atlas <[e-mail]<mailto:[e-mail]>> wrote:

Hi Carlos,

First, thanks for the updated version -21.

The rest is inline.

On Mon, Sep 18, 2017 at 2:14 PM, Carlos Pignataro (cpignata) <[e-mail]<mailto:[e-mail]>> wrote:
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]<mailto:[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.

My concern is the following example.  Say that an operator wants to do the equivalent of a traceroute to see how a packet is put into an SFP and what SFs it goes through (or maybe just SFFs).  Assume that is done by setting the O bit in the first NSH and then the encapsulated packet has duplicated contents to be guided properly.  If that packet then is reclassified, is the O bit cleared?

I have a real hesitation here about the future interoperability of something like traceroute,  if the behavior for the treatment of the O bit isn't specified for (re)classifiers.  For instance, if an SF or SFF doesn't support this new NSH-traceroute, then a hop would be skipped in the report back - but if the (re)classifier does it wrong, then all the hops downstream of the (re)classifier will suffer.

Do you or others have data on what current implementations are doing as part of reclassification? My interest isn't in changing the behavior (hopefully it is being done consistently) but in clearly documenting the expectations.


> 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?

Survival through a reclassifier is what I am thinking about.
In one model, there is the ability to pass along flags with a packet from the initial classification until the end of the SFC.
In another model, the flags only survive until the first reclassifier.
What one can do with these flags is different.
IMHO, it'd be better to clarify that unassigned flags should be copied transparently from an old NSH to a new/updated NSH.
Then, when and if the flags are assigned meanings, that can inform and change what classifiers that understand the flag
meaning will do.

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

This is a good start.  I'd add that standardized protocols should have preference and
if the range goes over 50% allocated, then IANA should alert the responsible AD so
that a new policy can be considered.

Thanks,
Alia

>
> Regards,
> Alia

—
Carlos Pignataro, [e-mail]<mailto:[e-mail]>

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