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

[Alia Atlas <[e-mail]>]

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]> 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]> 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]
>
> “Sometimes I use big words that I do not fully understand, to make myself
> sound more photosynthesis."
>
>