Subject: [sfc] Suresh Krishnan's Discuss on draft-ietf-sfc-nsh-24: (with DISCUSS and COMMENT)

From: Suresh Krishnan <[email-masked]>
Date: Thu, 28 Sep 2017 01:21:33 -0700

Suresh Krishnan has entered the following ballot position for
draft-ietf-sfc-nsh-24: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

* Section 5

I think the fragmentation part is underspecified. Take an example where IPv6 is
used as the transport encapsulation. If the packet needs to be fragmented, will
the NSH header be duplicated into each fragment? If so, this is new behavior
for IP that will treat this like any other payload. If not how will the
subsequent fragments be treated on the service path?

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

* Section 1.2.

The definition of metadata seems to point to RFC7665 but the definition that
follows does not match the definition from RFC7665.

* Section 2.2

What does a "Next Protocol" with the value of 0x4 (NSH) mean? Does the NSH
allow nesting. How will such system work?

* Section 3

"The O bit, as well as unassigned flags, MUST be copied transparently from the
old NSH to a new NSH."

If there is reclassification, why is there an assumption that an OAM packet
cannot be reclassified into a non OAM packet since a new NSH header is being
inserted?

* Section 8.1.
   Not sure what the reference to BCP38 means here. Is it for checking the
   source addresses the inner header that is getting encapsulated inside the
   NSH header? Or is it for the transport encapsulation header. Either way it
   is not clear what this entails. Please clarify.

* Section 11.1

This section mentions that ethertype 0x894F has been allocated for NSH. Are
there any other transport encapsulations planned? If not, I would recommend
tightening the text around the transport encapsulations until other
encapsulations are more well defined. e.g. How does the UDP transport
encapsulation referred in the example work?

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 28 Sep 2017 08:34:06 -0400

In order for your question to apply, I think we the situation would have 
to be one where both the outer tunnel (the transport protocol) and the 
user packet could be fragmented.  As the NSH behavior is uniform across 
inner packets (e.g. they can be Ethernet or other non-fragmentable 
content), the intent is that any fragmentation need for the transport 
tunnel would be done as part of the transport protocol operation.

Thus, if IPv6 is beign used as the transport protocol, the IPv6 packet 
will be addressed to the next SFF.  If fragmentation is needed, that 
IPv6 paket would be fragmented before transmission.  And would be 
reassembled by the receiving SFF IPv6 logic.
In no case would the NSH header be duplicated as part of this process.

We can add some text to clarify this.

Yours,
Joel

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 28 Sep 2017 12:58:01 +0000

Thanks Suresh for the review and comments! Please see inline.

> On Sep 28, 2017, at 4:21 AM, Suresh Krishnan <[email-masked]> wrote:
> 
> I think the fragmentation part is underspecified.

Joel’s respond explains this, but just for completeness taking a slightly different angle.

Perhaps it needs additional clarity, but the net of this section is that it is not specifying any new type of fragmentation (it cannot really be underspecified).

First, NSH does not provide fragmentation. Instead it relies in the underlying transport encapsulation for it. Take a case in which NSH is encapsulated in some NVO3 encapsulation and then over IPv6. This is done to move the NSH from an SFC-aware element to the next (SF/SFF/SFC-Proxy). If the NVO3 encapsulation does not provide fragmentation either, then regular vanilla IPv6 frag is performed.

> Take an example where IPv6 is
> used as the transport encapsulation.

Now, onto your example on which NSH goes over IPv6, either directly or via other encapsulation that does not provide fragmentation either.

> If the packet needs to be fragmented, will
> the NSH header be duplicated into each fragment?

No. Opaque payload as far as IPv6 is concerned, regular vanilla fragmentation, and reassembly before passing onto NSH.

> If so, this is new behavior
> for IP that will treat this like any other payload.

No new behavior.

> If not how will the

They are reassembled before hitting the next SFC-aware element.

Does that clarify?

Anything missing in the text from your perspective?

Some Directorate reviewer commented earlier that the definition of RFC7665 was not sufficient. Consequently, we added more color expanding the def.

> allow nesting. How will such system work?

Not specified here in this spec. It is being defined in draft-ietf-sfc-hierarchical.

We will clarify that in this document.

> cannot be reclassified into a non OAM packet since a new NSH header is being

A non-OAM packet is a user packet, we do not want to “create” user packets mid-stream.

>   is not clear what this entails. Please clarify.

Taken out as per Kathleen’s comment.

> encapsulation referred in the example work?

Part of making this document transport encapsulation agnostic is to not define those specifics. The only exception as you note is the etype, which needs to be somewhere.

Thanks!

Carlos.