Subject: [sfc] Update to NSH spec - Unknown Next Protocol

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 18 Jul 2017 09:12:43 +0100

Hi,

As we have been discussing we need to describe what implementations should do
with unknown "Next Protocol" values. We also need to not block the future use of
0x0 (which we might want for "none").

I think we need the following two changes. My words in the last paragraph of 2.2
seem excessive and I would be happy to see them reduced.

(Note that a couple of typos are also fixed in the changed text.)

Adrian

---

Section 2.2
OLD
   Next Protocol: indicates the protocol type of the encapsulated data.
   NSH does not alter the inner payload, and the semantics on the inner
   protocol remain unchanged due to NSH service function chaining.
   Please see the IANA Considerations section below, Section 11.2.5.

   This document defines the following Next Protocol values:

   0x0: Reserved
   0x1: IPv4
   0x2: IPv6
   0x3: Ethernet
   0x4: NSH
   0x5: MPLS
   0xFE: Experiment 1
   0xFF: Experiment 2

   An implementation not explicitly configured for a specific experiment
   [RFC3692] SHOULD NOT attempt to process Next Protocol values 0xFE and
   0xFF.
NEW
   Next Protocol: indicates the protocol type of the encapsulated data.
   NSH does not alter the inner payload, and the semantics on the inner
   protocol remain unchanged due to NSH service function chaining.
   Please see the IANA Considerations section below, Section 11.2.5.

   This document defines the following Next Protocol values:

   0x1: IPv4
   0x2: IPv6
   0x3: Ethernet
   0x4: NSH
   0x5: MPLS
   0xFE: Experiment 1
   0xFF: Experiment 2

   An implementation not explicitly configured for a specific experiment
   [RFC3692] SHOULD NOT attempt to process Next Protocol values 0xFE and
   0xFF.  
   
   An implementation that does not recognize the Next Protocol value 
   SHOULD NOT attempt to examine or process the payload of a packet.  
   The meaning of this will depend on the role of a component within the
   SFC system.  For example, an SFF may be able to forward an NSH packet
   without reference to the payload, but an SF applies a function to the 
   payload and so might be expected to understand the Next Protocol type.
   By default, an implementation that needs to look at the payload of an
   NSH packet MUST drop packets with unknown Next Protocol, but this 
   behavior SHOULD be configurable.
END

---

11.2.5

OLD
   IANA is requested to set up a registry of "Next Protocol".  These are
   8-bit values.  Next Protocol values 1, 2, 3, 4, and 5 are defined
   in this document (see Table 7).  New values are assigned via "Expert
   Review" as per [RFC8126].

             +---------------+--------------+---------------+
             | Next Protocol | Description  | Reference     |
             +---------------+--------------+---------------+
             | 0             | Unassigned   |               |
             |               |              |               |
             | 1             | IPv4         | This document |
             |               |              |               |
             | 2             | IPv6         | This document |
             |               |              |               |
             | 3             | Ethernet     | This document |
             |               |              |               |
             | 4             | NSH          | This document |
             |               |              |               |
             | 5             | MPLS         | This document |
             |               |              |               |
             | 6..253        | Unassigned   |               |
             |               |              |               |
             | 254           | Experiment 1 | This document |
             |               |              |               |
             | 255           | Experiment 2 | This document |
             +---------------+--------------+---------------+

               Table 7: NSH Base Header Next Protocol Values
NEW
   IANA is requested to set up a registry of "Next Protocol".  These are
   8-bit values.  Next Protocol values 1, 2, 3, 4, and 5 are defined
   in this document (see Table 7).  New values are assigned via "Expert
   Review" as per [RFC8126].

             +---------------+--------------+---------------+
             | Next Protocol | Description  | Reference     |
             +---------------+--------------+---------------+
             | 0             | Unassigned   |               |
             |               |              |               |
             | 1             | IPv4         | This document |
             |               |              |               |
             | 2             | IPv6         | This document |
             |               |              |               |
             | 3             | Ethernet     | This document |
             |               |              |               |
             | 4             | NSH          | This document |
             |               |              |               |
             | 5             | MPLS         | This document |
             |               |              |               |
             | 6..253        | Unassigned   |               |
             |               |              |               |
             | 254           | Experiment 1 | This document |
             |               |              |               |
             | 255           | Experiment 2 | This document |
             +---------------+--------------+---------------+

               Table 7: NSH Base Header Next Protocol Values
END

---

From: Dave Dolson <[email-masked]>
Date: Tue, 18 Jul 2017 08:41:46 +0000

What is the rationale to drop (vs skip) unrecognized next-protocol values?
And might the answer be different if O=1?

E.g., if an SF implementation does not recognize MPLS, ‎wouldn't it be best to just forward (and count error)?

David Dolson
Sandvine
  Original Message
From: Adrian Farrel
Sent: Tuesday, July 18, 2017 10:12 AM
To: [email-masked]
Reply To: [email-masked]
Subject: [sfc] Update to NSH spec - Unknown Next Protocol

Hi,

Adrian

---

Section 2.2
OLD

   0x0: Reserved
   0x1: IPv4
   0x2: IPv6
   0x3: Ethernet
   0x4: NSH
   0x5: MPLS
   0xFE: Experiment 1
   0xFF: Experiment 2

   0x1: IPv4
   0x2: IPv6
   0x3: Ethernet
   0x4: NSH
   0x5: MPLS
   0xFE: Experiment 1
   0xFF: Experiment 2

---

11.2.5

OLD

_______________________________________________
sfc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sfc

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 18 Jul 2017 05:19:11 -0400

Adrian,

Two comments.

1. It’s inconsistent to use 0xFE and 0xFF in the main text, but 254 and 255
in the IANA considerations. We should pick one or the other, and have it
the same at both places (I don’t have a particular preference).

2. Does the text:

mean drop or forward? We should be explicit what “NOT attempt to process”
actually means.

Thanks,
Andy

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 18 Jul 2017 10:28:48 +0100

Dave,
Yes, thanks, this is the discussion to have.

1. Suppose you are an SF and your job is to "do things" to IP packets. Suppose
you get an Ethernet frame, what do you do? Suppose you get a completely unknown
next protocol, what do you do?

I think the default needs to be "drop the packet" because you can't do your job,
but I also think you should be "configurable" such that your job definition
includes "forward untouched those packets you can't process."

But consider security SFs. They very probably should not forward packets that
they can't process.

2. Suppose you an SFC proxy. If you don't recognise the next protocol type, then
(presumably) your SF cannot process it and you should not pass it to the SF.

I think the default should be to drop the packet, but I can believe the desire
to configure that the proxy simply passes the packet back to the SFF.

But consider proxies to security SFs. They very probably should not return
packets to the SFF making it look like the security function has been performed.

3. Suppose you are a classifier (or re-classifier). Part of you classification
process is looking into the payload, but if you don't know the payload type, you
can't process it.

I think the default should be to drop the packet, but I can believe a
configuration that says "classify all unknown protocol types in the same way".

4. Suppose you are an SFF. In general you don't need to look at the next
protocol type and so the question does not arise (i.e., if you don't look at the
next protocol field, the value of the field cannot be unknown). 

On the other hand, if you are an SFF that is load balancing based on the payload
packet then you probably use the next protocol field to decide how to load
balance (i.e., how to interpret the payload packet).

In this case, I think the default should be to drop the packet, but I can
rationalise a configuration that says "load balance all unknown protocol types
in the same way".

5. Next protocol = "none" or other potential magic (such as OAM) fits, I think,
into the same four options. That is, if you need to understand the special
meaning of the next protocol field in order to correctly process the packet, and
if you don't understand the next protocol value, then you cannot properly
process the packet. 

Anyway, that was my thought process.

Adrian

> -----Original Message-----
> From: Dave Dolson [mailto:[email-masked]]
> Sent: 18 July 2017 09:42
> To: Adrian Farrel; [email-masked]
> Subject: Re: [sfc] Update to NSH spec - Unknown Next Protocol
> 
> E.g., if an SF implementation does not recognize MPLS, ‎wouldn't it be best to
just
> forward (and count error)?
> 
> David Dolson
> Sandvine
>   Original Message
> From: Adrian Farrel

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 18 Jul 2017 10:30:32 +0100

Fun, Andy!
 
The two questions apply to text I haven't modified.
I pass the questions on to WG/authors.
 
My opinions are:
1. Yes
2. Yes, we should be explicit.
 
A
 
From: Andrew G. Malis [mailto:[email-masked]] 
Sent: 18 July 2017 10:19
To: Adrian Farrel
Cc: [email-masked]
Subject: Re: [sfc] Update to NSH spec - Unknown Next Protocol
 
Adrian,
 
Two comments.
 
1. It’s inconsistent to use 0xFE and 0xFF in the main text, but 254 and 255 in the IANA considerations. We should pick one or the other, and have it the same at both places (I don’t have a particular preference).
 
2. Does the text:
 
   An implementation not explicitly configured for a specific experiment
   [RFC3692] SHOULD NOT attempt to process Next Protocol values 0xFE and
   0xFF.
mean drop or forward? We should be explicit what “NOT attempt to process” actually means.
 
Thanks,
Andy

Adrian

---

Section 2.2
OLD

   0x0: Reserved
   0x1: IPv4
   0x2: IPv6
   0x3: Ethernet
   0x4: NSH
   0x5: MPLS
   0xFE: Experiment 1
   0xFF: Experiment 2

   0x1: IPv4
   0x2: IPv6
   0x3: Ethernet
   0x4: NSH
   0x5: MPLS
   0xFE: Experiment 1
   0xFF: Experiment 2

---

11.2.5

OLD

---

From: Dave Dolson <[email-masked]>
Date: Tue, 18 Jul 2017 10:36:22 +0000

If I may paraphrase, we should set the operator's expectation that unknown=drop by default, because this will be less surprising than functions not being applied.

I'm OK with that.

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Tuesday, July 18, 2017 11:29 AM
To: Dave Dolson; [email-masked]
Subject: RE: [sfc] Update to NSH spec - Unknown Next Protocol

Dave,

1. Suppose you are an SF and your job is to "do things" to IP packets. Suppose you get an Ethernet frame, what do you do? Suppose you get a completely unknown next protocol, what do you do?

I think the default needs to be "drop the packet" because you can't do your job, but I also think you should be "configurable" such that your job definition includes "forward untouched those packets you can't process."

But consider security SFs. They very probably should not forward packets that they can't process.

I think the default should be to drop the packet, but I can believe the desire to configure that the proxy simply passes the packet back to the SFF.

But consider proxies to security SFs. They very probably should not return packets to the SFF making it look like the security function has been performed.

3. Suppose you are a classifier (or re-classifier). Part of you classification process is looking into the payload, but if you don't know the payload type, you can't process it.

I think the default should be to drop the packet, but I can believe a configuration that says "classify all unknown protocol types in the same way".

4. Suppose you are an SFF. In general you don't need to look at the next protocol type and so the question does not arise (i.e., if you don't look at the next protocol field, the value of the field cannot be unknown). 

On the other hand, if you are an SFF that is load balancing based on the payload packet then you probably use the next protocol field to decide how to load balance (i.e., how to interpret the payload packet).

In this case, I think the default should be to drop the packet, but I can rationalise a configuration that says "load balance all unknown protocol types in the same way".

5. Next protocol = "none" or other potential magic (such as OAM) fits, I think, into the same four options. That is, if you need to understand the special meaning of the next protocol field in order to correctly process the packet, and if you don't understand the next protocol value, then you cannot properly process the packet. 

Adrian

just
> As we have been discussing we need to describe what implementations 
> should do with unknown "Next Protocol" values. We also need to not 
> block the future use of
> I think we need the following two changes. My words in the last 
> paragraph of
2.2
>                Table 7: NSH Base Header Next Protocol Values NEW
>                Table 7: NSH Base Header Next Protocol Values END
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 18 Jul 2017 13:10:06 +0100

Dave,
Why shouldn't I use 1000 words where 22 would do?

;-)

Adrian

> Sent: 18 July 2017 11:36
> To: [email-masked]; [email-masked]
> If I may paraphrase, we should set the operator's expectation that
> unknown=drop by default, because this will be less surprising than functions
not
> being applied.
> you get an Ethernet frame, what do you do? Suppose you get a completely
> unknown next protocol, what do you do?
> 
to
> configure that the proxy simply passes the packet back to the SFF.
> 
process is
> looking into the payload, but if you don't know the payload type, you can't
> process it.
> 
configuration
> that says "classify all unknown protocol types in the same way".
> 
protocol
> type and so the question does not arise (i.e., if you don't look at the next
> protocol field, the value of the field cannot be unknown).
> 
rationalise
> a configuration that says "load balance all unknown protocol types in the same
> way".
> 
> 5. Next protocol = "none" or other potential magic (such as OAM) fits, I
think, into
> the same four options. That is, if you need to understand the special meaning
of
> the next protocol field in order to correctly process the packet, and if you
don't
> understand the next protocol value, then you cannot properly process the
> packet.
> 
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 18 Jul 2017 23:34:12 +0000

Thanks Adrian, Andy, and Dave!

Closing the loop on all these points, as well as next steps for the NSH doc, planned updates:

1. Specify protocol 0x0 is unassigned instead of reserved. This is so that other document can define it.
1.5. Will not merge in Protocol = 0. That should be advanced via Adrian's draft, just as any other protocol support allocation, assignment, and specification.
2. Add that "unknown protocol ids SHOULD be silently dropped", clarifying that behavior.
3. Allow different MD Type in a single SFP, like: "NSH does not disallow it, but such functionality would need to be explicitly specified."
4. Will update the IANA numbers to hex
5. Will change The should not process to SHOULD be drop for experimental protocols.

That's the scope of plan changes. All good useful things, though we have entered the diminishing returns territory.

Sent from my iPad

On Jul 18, 2017, at 11:19 AM, Andrew G. Malis <[email-masked]<mailto:[email-masked]>> wrote:

Adrian,

Two comments.

2. Does the text:

Thanks,
Andy

On Tue, Jul 18, 2017 at 4:12 AM, Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Adrian

---

Section 2.2
OLD

   0x0: Reserved
   0x1: IPv4
   0x2: IPv6
   0x3: Ethernet
   0x4: NSH
   0x5: MPLS
   0xFE: Experiment 1
   0xFF: Experiment 2

   0x1: IPv4
   0x2: IPv6
   0x3: Ethernet
   0x4: NSH
   0x5: MPLS
   0xFE: Experiment 1
   0xFF: Experiment 2

---

11.2.5

OLD

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

---

From: Dave Dolson <[email-masked]>
Date: Wed, 19 Jul 2017 02:47:56 +0000

Can 2 be "SHOULD be dropped by default but MAY be configured to ‎forward"? Or is that obvious?

David Dolson
Sandvine
From: Carlos Pignataro (cpignata)
Sent: Wednesday, July 19, 2017 1:34 AM
To: Andrew G. Malis
Cc: Adrian Farrel; [email-masked]
Subject: Re: [sfc] Update to NSH spec - Unknown Next Protocol

Sent from my iPad

Adrian,

Two comments.

2. Does the text:

Thanks,
Andy

Adrian

---

Section 2.2
OLD

   0x0: Reserved
   0x1: IPv4
   0x2: IPv6
   0x3: Ethernet
   0x4: NSH
   0x5: MPLS
   0xFE: Experiment 1
   0xFF: Experiment 2

   0x1: IPv4
   0x2: IPv6
   0x3: Ethernet
   0x4: NSH
   0x5: MPLS
   0xFE: Experiment 1
   0xFF: Experiment 2

---

11.2.5

OLD

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 19 Jul 2017 07:39:55 +0000

Thanks Dave. I think it is implicit in the SHOULD -- we recommend a behavior but there may be valid reasons to do something different, with appropriate reflection about potential consequences.

Sent from my iPad

On Jul 19, 2017, at 4:48 AM, Dave Dolson <[email-masked]<mailto:[email-masked]>> wrote:

David Dolson
Sandvine
From: Carlos Pignataro (cpignata)
Sent: Wednesday, July 19, 2017 1:34 AM
To: Andrew G. Malis
Cc: Adrian Farrel; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] Update to NSH spec - Unknown Next Protocol

Sent from my iPad

Adrian,

Two comments.

2. Does the text:

Thanks,
Andy

Adrian

---

Section 2.2
OLD

   0x0: Reserved
   0x1: IPv4
   0x2: IPv6
   0x3: Ethernet
   0x4: NSH
   0x5: MPLS
   0xFE: Experiment 1
   0xFF: Experiment 2

   0x1: IPv4
   0x2: IPv6
   0x3: Ethernet
   0x4: NSH
   0x5: MPLS
   0xFE: Experiment 1
   0xFF: Experiment 2

---

11.2.5

OLD

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 19 Jul 2017 09:09:51 +0100

In general, it is worth explaining the converse of the SHOULD (i.e., the MAY)
even if *we* think it is obvious.
 
This stops the ADs coming back and placing a Discuss because the document "is
not complete"
 
:-)
 
From: Carlos Pignataro (cpignata) [mailto:[email-masked]] 
Sent: 19 July 2017 08:40
To: Dave Dolson
Cc: Andrew G. Malis; Adrian Farrel; [email-masked]
Subject: Re: [sfc] Update to NSH spec - Unknown Next Protocol
 
Thanks Dave. I think it is implicit in the SHOULD -- we recommend a behavior but
there may be valid reasons to do something different, with appropriate
reflection about potential consequences. 

Sent from my iPad

On Jul 19, 2017, at 4:48 AM, Dave Dolson <[email-masked]> wrote:
Can 2 be "SHOULD be dropped by default but MAY be configured to ‎forward"? Or is
that obvious?

David Dolson
Sandvine

Closing the loop on all these points, as well as next steps for the NSH doc,
planned updates:
 
1. Specify protocol 0x0 is unassigned instead of reserved. This is so that other
document can define it. 
1.5. Will not merge in Protocol = 0. That should be advanced via Adrian's draft,
just as any other protocol support allocation, assignment, and specification. 
2. Add that "unknown protocol ids SHOULD be silently dropped", clarifying that
behavior. 
3. Allow different MD Type in a single SFP, like: "NSH does not disallow it, but
such functionality would need to be explicitly specified."
4. Will update the IANA numbers to hex
5. Will change The should not process to SHOULD be drop for experimental
protocols. 

That's the scope of plan changes. All good useful things, though we have entered
the diminishing returns territory. 
Sent from my iPad

On Jul 18, 2017, at 11:19 AM, Andrew G. Malis <[email-masked]> wrote:
Adrian, 
 
Two comments.
 
1. It’s inconsistent to use 0xFE and 0xFF in the main text, but 254 and 255 in
the IANA considerations. We should pick one or the other, and have it the same
at both places (I don’t have a particular preference).
 
2. Does the text:

Thanks,
Andy

Adrian

---

Section 2.2
OLD

   0x0: Reserved
   0x1: IPv4
   0x2: IPv6
   0x3: Ethernet
   0x4: NSH
   0x5: MPLS
   0xFE: Experiment 1
   0xFF: Experiment 2

   0x1: IPv4
   0x2: IPv6
   0x3: Ethernet
   0x4: NSH
   0x5: MPLS
   0xFE: Experiment 1
   0xFF: Experiment 2

---

11.2.5

OLD

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 19 Jul 2017 06:34:04 -0400

Carlos,

-15 takes care of my comments, thanks!

Cheers,
Andy

On Tue, Jul 18, 2017 at 7:34 PM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> 1.5. Will not merge in Protocol = 0. That should be advanced via Adrian's
> draft, just as any other protocol support allocation, assignment, and
> specification.
> 3. Allow different MD Type in a single SFP, like: "NSH does not disallow
> it, but such functionality would need to be explicitly specified."
> That's the scope of plan changes. All good useful things, though we have
> entered the diminishing returns territory.
>
> Sent from my iPad
>
> 1. It’s inconsistent to use 0xFE and 0xFF in the main text, but 254 and
> 255 in the IANA considerations. We should pick one or the other, and have
> it the same at both places (I don’t have a particular preference).
>
> 2. Does the text:
>
>> should do

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 19 Jul 2017 19:30:23 +0000

Adrian, Dave, we can add this.
Andrew, thanks much for checking your comments are addressed.
Med, thank you for the additional text and editorials. All addressed.

All,

Based on Med's most recent set of comments in Prague, I also identified a few small fixes in the field definitions and associated IANA parameter assignment requests. For example, from RFC 8126, Reserved is very different from Unassigned.

Since version numbers are cheap, new revision being submitted now.

FIN

Thanks!

Sent from my iPad

On Jul 19, 2017, at 10:10 AM, Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:

In general, it is worth explaining the converse of the SHOULD (i.e., the MAY) even if *we* think it is obvious.

This stops the ADs coming back and placing a Discuss because the document "is not complete"

:-)

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: 19 July 2017 08:40
To: Dave Dolson
Cc: Andrew G. Malis; Adrian Farrel; [email-masked]<mailto:[email-masked]>
Subject: Re: [sfc] Update to NSH spec - Unknown Next Protocol

Sent from my iPad

David Dolson
Sandvine

Two comments.

2. Does the text:

Thanks,
Andy

Adrian

---

Section 2.2
OLD

   0x0: Reserved
   0x1: IPv4
   0x2: IPv6
   0x3: Ethernet
   0x4: NSH
   0x5: MPLS
   0xFE: Experiment 1
   0xFF: Experiment 2

   0x1: IPv4
   0x2: IPv6
   0x3: Ethernet
   0x4: NSH
   0x5: MPLS
   0xFE: Experiment 1
   0xFF: Experiment 2

---

11.2.5

OLD