Subject: [sfc] Alvaro Retana's No Objection on draft-ietf-sfc-nsh-24: (with COMMENT)

From: Alvaro Retana <[email-masked]>
Date: Tue, 26 Sep 2017 12:17:07 -0700

Alvaro Retana 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:
----------------------------------------------------------------------

(1) While describing the MD Type field, Section 2.2. (NSH Base Header) talks
about the specific scenario in which "a device will support MD Type 0x1 (as per
the MUST) metadata, yet be deployed in a network with MD Type 0x2 metadata
packets", and it specifies that "the MD Type 0x1 node, MUST utilize the base
header length field to determine the original payload offset if it requires
access to the original packet/frame."  This is the case where the node in
question *does not* support MD Type 0x2, right?  If so, then the specification
above seems to go against (in the last sentence of the same paragraph):
"Packets with MD Type values not supported by an implementation MUST be
silently dropped."  IOW, if the node doesn't support 0x2, why wouldn't it just
drop the packet?

(2) Section 2.5.1. (Optional Variable Length Metadata) says that this document
"does not make any assumption about Context Headers that are
mandatory-to-implement or those that are mandatory-to-process.  These
considerations are deployment-specific."  But the next couple of paragraphs
specify explicit actions for them (mandatory-to-process):

   Upon receipt of a packet that belongs to a given SFP, if a mandatory-
   to-process context header is missing in that packet, the SFC-aware SF
   MUST NOT process the packet and MUST log an error at least once per
   the SPI for which the mandatory metadata is missing.

   If multiple mandatory-to-process context headers are required for a
   given SFP, the control plane MAY instruct the SFC-aware SF with the
   order to consume these Context Headers.  If no instructions are
   provided and the SFC-aware SF will make use of or modify the specific
   context header, then the SFC-aware SF MUST process these Context
   Headers in the order they appear in an NSH packet.

Maybe I'm confused about considerations being deployment specific vs specifying
what to do here.  Can you please clarify?

(3) "SFFs MUST use the Service Path Header for selecting the next SF or SFF in
the service path."  Section 6 explains most of what has to be done -- what I
think is still not clear in this document is where the information in Tables
1-4 comes from.  There may be different ways for an SFF to learn that, and I
would imagine that it is out-of-scope of this document.  Please say so -- maybe
there's a relevant reference to rfc7665 (?).

(4) Section 11.1. (NSH EtherType) seems out of place in this document because
(1) the document doesn't discuss the transport itself, and (2) it is in the
IANA section...

(5) What is the "IETF Base NSH MD Class" (Section 11.2.4)?  Ahh, I see that
Section 11.2.6 talks about "the type values owned by the IETF"; it would be
good to say that MD Class 0x0000 is being assigned to the IETF (in 11.2.4).

Nits:

In section 2.2. (NSH Base Header), it would be nice to have a forward reference
when the Service Index is first mentioned.

It may be nice to explicitly state in the description of the MD Type field
(Section 2.2) that for length = 0x2 and MD Type = 0x2, there are in fact no
optional context headers. (I know there's some text about this later in section
2.5.)

"...all domain edges MUST filter based on the carried protocol in the
VxLAN-gpe".  That "MUST" is out of place because the text is an example.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 26 Sep 2017 15:39:26 -0400

Thank you Alvaro.
I can comment on some of these, as I think we need some assistance 
finding better words.  The rest I will leave to Carlos.

Your comment 1 is about non-support of MD2 and the requirement that the 
entity use the length field anyway.
What we are trying to communicate (and have not gotten right) is that 
devices which need the packet, but do not need the metadata, are 
required to cope with MD2 with a length greater than 2.  An example of 
such a device is an SFF which has multiple valid hosp along the SFP, and 
uses the underlying packet header fields to pick one.  It is required to 
function even when handed an MD2 packet.
This is part of a compromise to make MD2 usable even with devices that 
were built principally for MD1.
Can you suggest better wording.  (Given that this is the base section, I 
do not want a long example here.)

Your comment 2 asks about mandatory-to-implement and mandatory-to-deply 
metadata.  We are not defining what is mandatory to implement.  The text 
you ask about is not defining which things are mandatory to implement. 
Rather, it is talking about what a service function should do when it 
does not receive something it considers mandatory.
Is there a better way to say that?

On your question 4, we wanted to note the assignment.  I agree it is a 
bit odd.  Do you think we should remove it?

Yours,
Joel

---

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

Thank you for the comments, Alvaro!

Please see inline.

> On Sep 26, 2017, at 3:17 PM, Alvaro Retana (aretana) <[email-masked]> wrote:
> 

Joel already answered this point.

> what to do here.  Can you please clarify?

Joel also clarified this in his response — if you have improvements to the text for clarity let us know.

The idea is that this document does not specify what is mandatory to implement, only the treatment when that is the case.

> there's a relevant reference to rfc7665 (?).

The way in which an SFF learns info from that table is out of scope, in cases implementation specific and does not affect interoperability.  But the definitions in section 2 say cases where information is expected from the control plane and outside the scope of the NSH specification.

We are happy to clarify if there is something that is causing confusion — maybe you could suggest text to “say so”?

> IANA section…

You have a good point — Joel asked “ Do you think we should remove it?”

I think we should keep it in, because it is important information for an implementor to have, regardless of those two points. 

But perhaps it should be moved out of that section and into a separate non-normative section? Do you have recommendations there?

Alia was tracking the NSH EtherType value. Alia, thoughts?

> good to say that MD Class 0x0000 is being assigned to the IETF (in 11.2.4).

Great point. I will add cross-references in both 11.2.4 and 11.2.6 pointing to each other.

Also, moving 11.2.6 to be immediately after 11.2.4 will help as well.

Both done in our working copy.

> when the Service Index is first mentioned.

Sorry I did not follow. Section 2.1 shows the Base Header (Section 2.2) and the Service Path Header (Section 2.3).

Where would you like a forward pointer to the SI?

> optional context headers. (I know there's some text about this later in section

OK. Added, 

> VxLAN-gpe".  That "MUST" is out of place because the text is an example.

Great point. Fixed.

Thanks,

— Carlos.

---

From: Alia Atlas <[email-masked]>
Date: Wed, 27 Sep 2017 11:07:24 -0400

On Wed, Sep 27, 2017 at 12:14 AM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> The idea is that this document does not specify what is mandatory to
> implement, only the treatment when that is the case.
>
> >
> The way in which an SFF learns info from that table is out of scope, in
> cases implementation specific and does not affect interoperability.  But
> the definitions in section 2 say cases where information is expected from
> the control plane and outside the scope of the NSH specification.
>
> We are happy to clarify if there is something that is causing confusion —
> maybe you could suggest text to “say so”?
>
> >
> I think we should keep it in, because it is important information for an
> implementor to have, regardless of those two points.
>
> But perhaps it should be moved out of that section and into a separate
> non-normative section? Do you have recommendations there?
>

For implementations, it needs to stay in the document.
If having it in the IANA section is confusing, having a separate section is
fine.
There may still be some details to clear up with IEEE, since the original
owner of the EtherType is Cisco.

Regards,
Alia

> Sorry I did not follow. Section 2.1 shows the Base Header (Section 2.2)
> and the Service Path Header (Section 2.3).
>

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 27 Sep 2017 18:41:45 +0000

On 9/26/17, 3:39 PM, "Joel M. Halpern" <[email-masked]> wrote:

Joel:

Hi!

> Your comment 1 is about non-support of MD2 and the requirement that 
> the entity use the length field anyway.

My main concern is that the document says that packets with an unsupported MD Type “MUST be
silently dropped”.  The complication is that the document also specifies “partial” support for MD Type 2: “NSH implementations MUST support MD types 0x1 and 0x2 (where the length is 0x2).  NSH implementations SHOULD support MD Type 0x2 with length greater than 0x2.”  

It seems to me that putting a device that only supports one MD Type (or in this case partial support for another) in a network should not be expected to deal with supporting other types…and should be something highlighted for deployment consideration.

Having said that, here’s a suggestion:

OLD>
   …  There exists,
   however, a middle ground, wherein a device will support MD Type 0x1
   (as per the MUST) metadata, yet be deployed in a network with MD Type
   0x2 metadata packets.  In that case, the MD Type 0x1 node, MUST
   utilize the base header length field to determine the original
   payload offset if it requires access to the original packet/frame.

NEW>
   … Devices that don’t support MD Type 0x2 with length greater than 
   0x2 MUST ignore any optional context headers and process the packet 
   without them; the base header length field can be used to determine the 
   original payload offset if access to the original packet/frame is required. 

Thanks!

Alvaro.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 27 Sep 2017 14:43:35 -0400

Thanks Alvaro.  That change seems fine with me.

Yours,
Joel

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 27 Sep 2017 18:47:20 +0000

On 9/27/17, 12:14 AM, "Carlos Pignataro (cpignata)" <[email-masked]> wrote:

Carlos:

Hi!

…
> The way in which an SFF learns info from that table is out of scope, in cases 
> implementation specific and does not affect interoperability.  

I agree.

> But the definitions in section 2 say cases where information is expected from 

I looked, but couldn’t find where the text talks about information expected from the control plane.

In any case, here’s a suggestion: “The information contained in Tables 1-4 may be received from the control plane, but the exact mechanism is outside the scope of this document.”

… 
> Where would you like a forward pointer to the SI?

In section 2.2, where the TTL is being explained, it says: “This TTL field is the primary loop prevention This TTL mechanism represents a robust complement to the Service Index…”  However, the Service Index is not introduced until the next section.

Thanks!

Alvaro.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 27 Sep 2017 18:50:44 +0000

On 9/27/17, 11:07 AM, "Alia Atlas" <[email-masked]> wrote:

Hi!

> > > (4) Section 11.1. (NSH EtherType) seems out of place in this 
> > > document because (1) the document doesn't discuss the 
> > > transport itself, and (2) it is in the IANA section…
> >
> > I think we should keep it in, because it is important information
> > for an implementor to have, regardless of those two points.
> >
> > But perhaps it should be moved out of that section and into a 
> > separate non-normative section? Do you have recommendations 
> > there?
> >

The main reason I think it should be completely removed is because throughout the document the point about the NSH being transport independent is clearly made.  The EtherType information is transport-specific – I just don’t think it belongs here.

Alvaro.

---

From: Alia Atlas <[email-masked]>
Date: Wed, 27 Sep 2017 14:54:39 -0400

On Wed, Sep 27, 2017 at 2:50 PM, Alvaro Retana (aretana) <[email-masked]>
wrote:

> The main reason I think it should be completely removed is because
> throughout the document the point about the NSH being transport independent
> is clearly made.  The EtherType information is transport-specific – I just
> don’t think it belongs here.
>

If the WG had a transport-specific draft in progress, I'd agree with you.
Lacking such a vehicle...

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 27 Sep 2017 19:15:47 +0000

+1.

Incorporated.

—
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 2:43 PM, Joel M. Halpern <[email-masked]<mailto:[email-masked]>> wrote:

Yours,
Joel

On 9/26/17, 3:39 PM, "Joel M. Halpern" <[email-masked]<mailto:[email-masked]>> wrote:

Nits:

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 27 Sep 2017 19:22:00 +0000

Dear Alia,

On Sep 27, 2017, at 2:54 PM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Sep 27, 2017 at 2:50 PM, Alvaro Retana (aretana) <[email-masked]<mailto:[email-masked]>> wrote:
On 9/27/17, 11:07 AM, "Alia Atlas" <[email-masked]<mailto:[email-masked]>> wrote:

Hi!

If the WG had a transport-specific draft in progress, I'd agree with you.  Lacking such a vehicle...

Alvaro had two points. One you are addressing. The second one is whether the Ethertype Section should be within the IANA Considerations section.

Since you recommend we leave it in. Do you recommend we:
1. Leave it where it is?
2. Move is somewhere else (and where)?

Thanks,

Carlos.

---

From: Alia Atlas <[email-masked]>
Date: Wed, 27 Sep 2017 15:26:54 -0400

Dear Carlos,

On Wed, Sep 27, 2017 at 3:22 PM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> Dear Alia,
>
> On Sep 27, 2017, at 2:54 PM, Alia Atlas <[email-masked]> wrote:
>
>
>
> On Wed, Sep 27, 2017 at 2:50 PM, Alvaro Retana (aretana) <
> [email-masked]> wrote:
>
> Alvaro had two points. One you are addressing. The second one is whether
> the Ethertype Section should be within the IANA Considerations section.
>

Alvaro is right that it doesn't belong in the IANA Considerations section.
I'm reluctant to create a "Transport Overlays Considerations" section - so
perhaps an
"Information on NSH-Related Codepoints" would be good?

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 27 Sep 2017 19:31:29 +0000

Hi, Alvaro,

> On Sep 27, 2017, at 2:47 PM, Alvaro Retana (aretana) <[email-masked]> wrote:
> 

OK.

> In any case, here’s a suggestion: “The information contained in Tables 1-4 may be received from the control plane, but the exact mechanism is outside the scope of this document.”

Sure.

> In section 2.2, where the TTL is being explained, it says: “This TTL field is the primary loop prevention This TTL mechanism represents a robust complement to the Service Index…”  However, the Serv…

Got it. Sorry I missed it. Added a “(see Section 2.3)” parenthetical.

Thanks,

Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 27 Sep 2017 19:39:31 +0000

Perfect! Thanks!

—

On Sep 27, 2017, at 3:26 PM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:

Dear Carlos,

On Wed, Sep 27, 2017 at 3:22 PM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Dear Alia,

Hi!

Alvaro is right that it doesn't belong in the IANA Considerations section.
I'm reluctant to create a "Transport Overlays Considerations" section - so perhaps an
"Information on NSH-Related Codepoints" would be good?

Thanks,

Carlos.