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

From: Alia Atlas <[email-masked]>
Date: Thu, 7 Sep 2017 15:39:27 -0400

Carlos,

The draft is much improved.  Thank you for your hard work.  I still see the
following three issues.

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

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.

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

Regards,
Alia

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 18 Sep 2017 18:14:12 +0000

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 <[email-masked]> 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
> What happens if the packet is reclassified - potentially to a different SFP?  
> 

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

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

> Alia

—
Carlos Pignataro, [email-masked]

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

---

From: Alia Atlas <[email-masked]>
Date: Fri, 22 Sep 2017 16:25:27 -0400

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) <
[email-masked]> wrote:

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

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
> Sure. It’s already cited in the Security Considerations section, but we
> can add another citation. Done in the working copy.
>
> 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>

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 22 Sep 2017 16:38:31 -0400

Trimmed, with one piece retained as context.
If IANA is willing to accept a request for an alert, I can see using 
that.  and half is as good as any other percentage.

I do not know what it would mean in practice to add text saying that 
standardized protocols should have preference.  At least until we hit 
50%?  What would an expert do differently with or without that item?

Yours,
Joel

On 9/22/17 4:25 PM, Alia Atlas wrote:
...
>     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>

---

From: Alia Atlas <[email-masked]>
Date: Fri, 22 Sep 2017 16:43:25 -0400

> that.  and half is as good as any other percentage.

I would be startled to burn through that much, but this gives an alert
early enough that the IETF/WG process could respond.
Since IANA is responsible for recording the allocation, it should be
relatively easy to track and indicate.

> standardized protocols should have preference.  At least until we hit 50%?
> What would an expert do differently with or without that item?
>

My thought is to provide a bit of pressure for requests that are extremely
proprietary formats; it would be more relevant as and if the registry gets
fuller.

To be clearer - these are minor suggested refinements to improve - not
requirements to proceed.

Regards,
Alia

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 22 Sep 2017 20:53:51 +0000

These are good suggestions, Alia, that I believe we need to accommodate.

—
Carlos Pignataro, [email-masked]<mailto:[email-masked]>

On Sep 22, 2017, at 4:43 PM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, Sep 22, 2017 at 4:38 PM, Joel M. Halpern <[email-masked]<mailto:[email-masked]>> wrote:
Trimmed, with one piece retained as context.
If IANA is willing to accept a request for an alert, I can see using that.  and half is as good as any other percentage.

I would be startled to burn through that much, but this gives an alert early enough that the IETF/WG process could respond.
Since IANA is responsible for recording the allocation, it should be relatively easy to track and indicate.

I do not know what it would mean in practice to add text saying that standardized protocols should have preference.  At least until we hit 50%?  What would an expert do differently with or without that item?

My thought is to provide a bit of pressure for requests that are extremely proprietary formats; it would be more relevant as and if the registry gets fuller.

To be clearer - these are minor suggested refinements to improve - not requirements to proceed.

Regards,
Alia

Yours,
Joel

    Good point. Thanks.

    <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

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 22 Sep 2017 21:16:00 +0000

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!

—

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

Hi Carlos,

The rest is inline.

On Mon, Sep 18, 2017 at 2:14 PM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Alia,

> On Sep 7, 2017, at 3:39 PM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:
>
> Carlos,
>

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.

“Unassigned bits MUST

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.

Good point. Thanks.

<t>

Thanks,
Alia

—