Subject: [sfc] Spencer Dawkins' No Objection on draft-ietf-sfc-nsh-24: (with COMMENT)

From: Spencer Dawkins <[email-masked]>
Date: Tue, 26 Sep 2017 09:22:39 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-sfc-nsh-24: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for responding to Wes Eddy's TSV-ART review of -19 (and, of course,
for making text changes that seemed appropriate).

It seems to me that you describe expectations about the applicability of NSH in
various places in the document, and in various ways. You might consider (for
example) pulling the common elements of statements like (from Section 5)

   Within a managed administrative domain, an operator can ensure that
   the underlay MTU is sufficient to carry SFC traffic without requiring
   fragmentation.  Given that the intended scope of the NSH is within a
   single provider's operational domain, that approach is sufficient.

and (from Section 8)

  NSH is designed for use within operator environments.  As such, it
   does not include any mandatory security mechanisms.  As with many
   other protocols, without enhancements, the NSH encapsulation can be
   spoofed and is subject to snooping and modification in transit.

   However, the deployment scope (as defined in [RFC7665]) of the NSH
   encapsulation is limited to a single network administrative domain as
   a controlled environment, with trusted devices (e.g., a data center)
   hence mitigating the risk of unauthorized manipulation of the
   encapsulation headers or metadata.  This controlled environment is an
   important assumption for NSH.  There is one additional important
   assumption: All of the service functions used by an operator in
   service chains are assumed to be selected and vetted by the operator.

into one section describing the applicability of NSH, appearing MUCH earlier in
the document (the most detailed description of your expectations looks like it
appears in the Security Considerations section, but parts of that description
are applicable to the Fragmentation Considerations section, which appears three
sections earlier in the document). The reader would have your intended
applicability in mind much earlier and more clearly, and you could just invoke
your expectations by reference when you need to explain how they apply
elsewhere in the document, so the expectations in play would be consistent
across mentions throughout the document.

I'm still bothered that this document doesn't explicitly mention ICMP blocking
as a problem for PMTUD with IP encapsulations. We're just not good at path MTU
discovery, so it seems useful to call this out explicitly when a document
expects to use PMTUD. That way, people who use NSH will know to check for ICMP
blocking on their networks before they receive their first trouble reports.
This almost reached my threshold for balloting Discuss, so I'd hope you folks
would consider that.

I see that the applicability of NSH includes encapsulations that don't provide
a path MTU discovery mechanism, and that your resolution for those
encapsulations is to log events when a "too big" packet is dropped. Could you
educate me, as to whether all encapsulations detect that this is happening? It
might be that encapsulations are using a fixed maximum MTU by definition, so
that what you're logging is an attempt to send a payload that violates the
protocol definition of the encapsulation, but I don't know that that's true in
all cases, so thought I should ask.

I saw a suggestion from Joe Touch (in a response to the TSV-ART review) to
consider looking at the terminology developed for draft-ietf-intarea-tunnels. I
didn't see a reply to that suggestion, and I didn't see a reference to
draft-ietf-intarea-tunnels in -24 - was this considered?

(I'm also asking because I want to keep track of whether people applying
encapsulations find that document useful, of course)

(Joe's follow-up is at
https://mailarchive.ietf.org/arch/msg/tsv-art/CsdWwR9B5_AB64D0eFl-KIE7_NA)

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 27 Sep 2017 03:43:09 +0000

Many thanks Spencer for the comments below!

Please see inline.

> On Sep 26, 2017, at 12:22 PM, Spencer Dawkins <[email-masked]> wrote:
> 

Thanks to Wes for taking the time to review!

We did go over the whole document with a fine comb cleaning up terms based on Wes’ feedback.

> across mentions throughout the document.

We are very hesitant to make drastic structural modifications to the document at this stage.

I understand your point about compiling a list of expectations throughout the document into a self-contained index. However, those expectations are very different for each area (e.g., security, encapsulation transport, etc.) and are currently functionally organized. The goal is not to have a list of requirements, but have implementors functionally read through the complete specification.

Based on earlier feedback, we did present a more deliberate and intentional applicability early on, in the Introduction. See third-to-last paragraph of Section 1.

> as a problem for PMTUD with IP encapsulations.

We do not want to take away from the focus of the document, to have an analysis of PMTUD. Doing so would be unfair to PMTUD, and invariably incorrect by omission. There are other things that break PMTUD too potentially, and other risks such as ICMP attacks, etc.

Given the fact that the IP encapsulation can be IPv4 or IPv6, we do not want to explain PMTUD.

That said, if there is a single Reference that you feel captures the PMTUD problems and guidance, we will be happy to add it!

> We're just not good at path MTU

We are considering and happy to add some text about the problem. However, we were unable to find a single reference that atomically describes the problem and gives recommendation. Even RFC 8201 includes only a single-sentence lost in middle of the Introduction.

Proposal:

OLD:
   For example, when the NSH is encapsulated in IP, IP-level
   fragmentation coupled with Path MTU Discovery (PMTUD) is used. 

NEW:

   For example, when the NSH is encapsulated in IP, IP-level
   fragmentation coupled with Path MTU Discovery (PMTUD) is used.  Since
   PMTUD relies on ICMP messages, an operator should ensure ICMP
   packets are not blocked.

But a citation would enrich this. Please let us know. RFC 2923 is too TCP specific, etc...

> all cases, so thought I should ask.

We cannot prove if *all* encapsulations detect that as happening, as you are asking. However, if an encapsulation drops a packet for that reason we are adding a requirement for those encaps. 

> draft-ietf-intarea-tunnels in -24 - was this considered?

Apologies for not having responded. Yes, this was considered.

The needs of draft-ietf-sfc-nsh are so basic in this regards that we use only two terms. Those two terms are exact terms defined in draft-ietf-intarea-tunnels. MTU and PMTUD. This document does not make use of things like EMTU_R.

> encapsulations find that document useful, of course)

I reviewed an earlier iteration of that document, almost a decade ago (!!) and sent pages of comments. I also reviewed a subsequent intarea WG version of it. The applicability of that doc to draft-ietf-sfc-nsh is quite limited. 

By the way, the treatment of ICMP blockage in draft-ietf-intarea-tunnels is quite not exhaustive — and that document seems a better place for complaining about ICMP and PMTUD.

> https://mailarchive.ietf.org/arch/msg/tsv-art/CsdWwR9B5_AB64D0eFl-KIE7_NA)

Thanks again!

— Carlos.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 27 Sep 2017 14:29:17 +0800

Hi, Carlos,

On Sep 27, 2017 11:43, "Carlos Pignataro (cpignata)" <[email-masked]>
wrote:

Please see inline.

We did go over the whole document with a fine comb cleaning up terms based
on Wes’ feedback.

> across mentions throughout the document.

We are very hesitant to make drastic structural modifications to the
document at this stage.

Understood :-)

I understand your point about compiling a list of expectations throughout
the document into a self-contained index. However, those expectations are
very different for each area (e.g., security, encapsulation transport,
etc.) and are currently functionally organized. The goal is not to have a
list of requirements, but have implementors functionally read through the
complete specification.

Right, but the problem is that the expectations that kept me from balloting
Discuss were three sections after the section TSV ADs turn to
automatically. So our mileage for functional organization differs.

ISTM that providing key information allowing an informed decision about
whether to use this mechanism in the 8th section, under security
considerations, is really waiting until the last minute. Suspense is good
for novels, but maybe not for implementers and operators.

This isn't quite as late as adding MUSTs in the IANA considerations
section, but it's close.

If you can think of a better way to ensure that people making deployment
decisions understand the limitations, that would be good.

If not, it's a comment. Do the right thing, of course.

 Based on earlier feedback, we did present a more deliberate and
intentional applicability early on, in the Introduction. See third-to-last
paragraph of Section 1.

That definitely helps. Thanks for that.

> as a problem for PMTUD with IP encapsulations.

We do not want to take away from the focus of the document, to have an
analysis of PMTUD. Doing so would be unfair to PMTUD, and invariably
incorrect by omission. There are other things that break PMTUD too
potentially, and other risks such as ICMP attacks, etc.

Given the fact that the IP encapsulation can be IPv4 or IPv6, we do not
want to explain PMTUD.

That said, if there is a single Reference that you feel captures the PMTUD
problems and guidance, we will be happy to add it!

> This almost reached my threshold for balloting Discuss, so I'd hope you
folks

We are considering and happy to add some text about the problem. However,
we were unable to find a single reference that atomically describes the
problem and gives recommendation. Even RFC 8201 includes only a
single-sentence lost in middle of the Introduction.

The reason coming up with a reference for this is hard, is because we're
just not very good at path MTU discovery  :p

But 8201 is possibly the best reference available (recent Internet
Standard). Do the right thing ...

Proposal:

OLD:

NEW:

But a citation would enrich this. Please let us know. RFC 2923 is too TCP
specific, etc...

This text is helpful. If mentioning 8201 somewhere seems helpful, that
would be fine with me.

> all cases, so thought I should ask.

We cannot prove if *all* encapsulations detect that as happening, as you
are asking. However, if an encapsulation drops a packet for that reason we
are adding a requirement for those encaps.

Perfect.

The needs of draft-ietf-sfc-nsh are so basic in this regards that we use
only two terms. Those two terms are exact terms defined in
draft-ietf-intarea-tunnels. MTU and PMTUD. This document does not make use
of things like EMTU_R.

Thanks for the feedback.

> encapsulations find that document useful, of course)

I reviewed an earlier iteration of that document, almost a decade ago (!!)
and sent pages of comments. I also reviewed a subsequent intarea WG version
of it. The applicability of that doc to draft-ietf-sfc-nsh is quite limited.

By the way, the treatment of ICMP blockage in draft-ietf-intarea-tunnels is
quite not exhaustive — and that document seems a better place for
complaining about ICMP and PMTUD.

Perhaps so.

Thanks for all this.

Spencer

Thanks again!

— Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 27 Sep 2017 11:49:58 +0000

Hi, Spencer,

Thank you for your quick and thoughtful response.

> If not, it's a comment. Do the right thing, of course.

We take the comment seriously as it is a unique last opportunity to improve, and  really appreciate the “Do the right thing” approach.

Specifics inline.

> On Sep 27, 2017, at 2:29 AM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> Hi, Carlos,
> 
> On Sep 27, 2017 11:43, "Carlos Pignataro (cpignata)" <[email-masked]> wrote:
> Right, but the problem is that the expectations that kept me from balloting Discuss were three sections after the section TSV ADs turn to automatically. So our mileage for functional organization differs.
> 
> ISTM that providing key information allowing an informed decision about whether to use this mechanism in the 8th section, under security considerations, is really waiting until the last minute. Suspense is good for novels, but maybe not for implementers and operators.
> 
> This isn't quite as late as adding MUSTs in the IANA considerations section, but it's close.
> 
> If you can think of a better way to ensure that people making deployment decisions understand the limitations, that would be good. 
> 

I think what you are after is mostly contained in the last 4 paragraphs of the Introduction. Would it help if we place those under a sub-heading “1.1 Scope” or “1.1 Applicability”?

> The reason coming up with a reference for this is hard, is because we're just not very good at path MTU discovery  :p
> 
> But 8201 is possibly the best reference available (recent Internet Standard). Do the right thing ...
> 
> 
> Proposal:
> 
> OLD:
> This text is helpful. If mentioning 8201 somewhere seems helpful, that would be fine with me.
> 

Sounds good. Added both the text and a citation.

> By the way, the treatment of ICMP blockage in draft-ietf-intarea-tunnels is quite not exhaustive — and that document seems a better place for complaining about ICMP and PMTUD.

Thank you, Spencer!

— Carlos.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 27 Sep 2017 20:05:16 +0800

Hi, Carlos,

On Sep 27, 2017 19:50, "Carlos Pignataro (cpignata)" <[email-masked]>
wrote:

Hi, Spencer,

> If not, it's a comment. Do the right thing, of course.

We take the comment seriously as it is a unique last opportunity to
improve, and  really appreciate the “Do the right thing” approach.

Specifics inline.

document at this stage.
>
> Right, but the problem is that the expectations that kept me from
balloting Discuss were three sections after the section TSV ADs turn to
automatically. So our mileage for functional organization differs.
section, but it's close.

I think what you are after is mostly contained in the last 4 paragraphs of
the Introduction. Would it help if we place those under a sub-heading “1.1
Scope” or “1.1 Applicability”?

This seems helpful. If it's useful for you to know, I'd prefer
Applicability, just because I think IETF is doing more specifications that
aren't generically deployable, and would like our readers and implementers
to be more aware of whether they should be using each cool new thing on
their own networks.

You may have noticed that most of our recent tunneling specifications break
congestion considerations into two sections - one, saying what's safe to
deploy anywhere, and one saying what you can probably get away with if your
network is closely monitored.

We want people to be very aware of applicability considerations in many
cases.

want to explain PMTUD.
>
> That said, if there is a single Reference that you feel captures the
PMTUD problems and guidance, we will be happy to add it!
specific, etc...
would be fine with me.

Thanks. I think you're good to go.

Spencer

> I reviewed an earlier iteration of that document, almost a decade ago
(!!) and sent pages of comments. I also reviewed a subsequent intarea WG
version of it. The applicability of that doc to draft-ietf-sfc-nsh is quite
limited.
>
> By the way, the treatment of ICMP blockage in draft-ietf-intarea-tunnels
is quite not exhaustive — and that document seems a better place for
complaining about ICMP and PMTUD.

Thank you, Spencer!

— Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 27 Sep 2017 12:07:16 +0000

Sounds like a good approach, Spencer. Done.

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

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

On Sep 27, 2017, at 8:05 AM, Spencer Dawkins at IETF <[email-masked]<mailto:[email-masked]>> wrote:

Hi, Carlos,

On Sep 27, 2017 19:50, "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Spencer,

Specifics inline.

> On Sep 27, 2017, at 2:29 AM, Spencer Dawkins at IETF <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi, Carlos,
>
> On Sep 27, 2017 11:43, "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>> wrote:
> > On Sep 26, 2017, at 12:22 PM, Spencer Dawkins <[email-masked]<mailto:[email-masked]>> wrote:
> >

This seems helpful. If it's useful for you to know, I'd prefer Applicability, just because I think IETF is doing more specifications that aren't generically deployable, and would like our readers and implementers to be more aware of whether they should be using each cool new thing on their own networks.

You may have noticed that most of our recent tunneling specifications break congestion considerations into two sections - one, saying what's safe to deploy anywhere, and one saying what you can probably get away with if your network is closely monitored.

We want people to be very aware of applicability considerations in many cases.

Spencer

Thank you, Spencer!

— Carlos.