Subject: Re: [sfc] SFC with next protocol = "None"

From: Dave Dolson <[email-masked]>
Date: Sun, 22 Jan 2017 17:52:37 +0000

Thanks Adrian, Lucy & John

After reading it, a question occurs to me about the nsh draft:
- does it properly specify forwarding behavior when Next-Protocol is an unsupported value? (SFF shouldn't care; SF or SFC Proxy should decrement SI and pass through). "None" should not be a special case of unsupported.

I'm inclined to say we should add None to the Next-Header values in the NSH document, and clarify forwarding behavior to support the ideas in your section 4 on Backward Compatibility. 

‎The use cases in your draft use concepts not defined by any adopted draft, such as semantics of metadata and using metadata for OAM. (We need to work on these!) I think many of suggestions apply for all Next-Protocol types.

-Dave

  Original Message  
From: Adrian Farrel
Sent: Sunday, January 22, 2017 11:23 AM
To: [email-masked]
Reply To: [email-masked]
Subject: [sfc] SFC with next protocol = "None"

Hi,

At the interim, Lucy and I took an action to write this draft. It allows you to
send metadata on an SFP without having a data packet to attach it to.

There was some discussion about whether this idea should find its way into the
base NSH draft. I said "no" because of the volume of material, because it is not
a fundamental of NSH, and because we don't want to hold up the publication of
the NSH spec. That said, if the WG wants to fold it in, I won't object.

Please review and comment. We think it is a simple idea and that the document
pretty much says it all.

Thanks,
Adrian

> -----Original Message-----
> From: I-D-Announce [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: 22 January 2017 16:17
> To: [email-masked]
> Subject: I-D Action: draft-farrel-sfc-convent-00.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> 
> 
> Title : Operating the Network Service Header with Next
Protocol "None"
> Authors : Adrian Farrel
> Lucy Yong
> John Drake
> Filename : draft-farrel-sfc-convent-00.txt
> Pages : 8
> Date : 2017-01-22
> 
> Abstract:
> This document describes the use of the Network Service Header (NSH)
> in a Service Function Chaining (SFC) overlay network with no payload
> data and only carrying metadata. This is achieved by defining a new
> "next protocol" type value of "None".
> 
> This document illustrates some of the functions that may be achieved
> or enhanced by this mechanism, but it does not provide an exhaustive
> list of use cases, nor is it intended to be definitive about the
> functions it describes. It is expected that other documents will
> describe specific use cases in more detail and will define the
> protocol mechanics for each use case.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-farrel-sfc-convent/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-farrel-sfc-convent-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 22 Jan 2017 22:41:23 -0000

Hey Dave,

> - does it properly specify forwarding behavior when Next-Protocol is an
> unsupported value? (SFF shouldn't care; SF or SFC Proxy should decrement SI and
> pass through).

Consider an SF needs to perform function on the packet. Hmm, that would be most SFs :-)
The Next Protocol is pretty fundamental to parsing the packet and working on it.
Now you *could* define an SF that passes "unknown" packets transparently. 
It's a policy issue at your SF, but I hope the firewalls I use don't have that policy.

So:
- Yes we should define the behavior on *all* unknown and unsupported values
  of all fields in the NSH. I believe we took an action in Westford to do that.
- For next protocol I think:
   - SFF should not examine, but should forward
   - SFC Proxy must not pass to an SF a packet of type that it cannot
      indicate to the SF
   - SFC Proxy must not pass to an SF a packet of type that the SF does
      not support
   - SFC should not return to the SFF a packet it has not passed to the SF
   - SF should not return to the SFF a packet it hasn't processed unless
     local policy defines "process" to mean "not process" in this case

> "None" should not be a special case of unsupported.

Hmmm. I think that is dangerous.
There is a big difference between an unknown data type and absent data.
I *do* agree that for implementations that don't support "None" there will be no distinction between "None" and "Unsupported"

> I'm inclined to say we should add None to the Next-Header values in the NSH
> document, and clarify forwarding behavior to support the ideas in your section 4
> on Backward Compatibility.

Like I said, the authors would be happy to see this go into the base NSH spec, but we don't think you can simply define the value in the IANA section without saying what it means. So some additional text would be needed as well (presumably culled from the draft).

And that leads to the question of how quickly the WG would reach consensus on this and get the draft updated.
I keep hearing "We have to get on and publish the NSH spec" and I didn't want to suggest changes that would only cause further delay.

As to your point...
 
> ‎The use cases in your draft use concepts not defined by any adopted draft, such
> as semantics of metadata and using metadata for OAM. (We need to work on
> these!) I think many of suggestions apply for all Next-Protocol types.

I'm not sure that the draft describes semantics of metadata. It does talk about the scope of the metadata (per SFP, per flow, per packet) and if this is what you mean, then all I can say is that the whole concept of metadata may be a little under-specified. 

You could be referring to two places where we make observations about the content of metadata. The first is where we say that if you want to support per-flow metadata in an NSH packet with Next Protocol = "None" the metadata will need to indicate which flow the metadata applies to. I believe this to be self-evident. The second case is where we say that metadata could contain OAM. You're correct that this has not been stated anywhere, but it is also "self-evident" from the current definition of the NSH.

Did I miss your point?

Cheers,
Adrian

---

From: Dave Dolson <[email-masked]>
Date: Mon, 23 Jan 2017 03:09:18 +0000

Adrian,

You make some good points. I'm still left with the impression that *some* things you say should make their way into the NSH draft.
Please see inline [DD]

I should say that I don't feel strongly about anything I've said; rather, I'm exploring questions that occurred to me while reading your draft.

-Dave

________________________________________
From: Adrian Farrel [[email-masked]]
Sent: Sunday, January 22, 2017 5:41 PM
To: Dave Dolson
Cc: [email-masked]
Subject: RE: [sfc] SFC with next protocol = "None"

Hey Dave,

[DD] Point taken. Then is "Empty" as special case?

So:

[DD] The net outcome being unknown next-header types are dropped somewhere?

Like I said, the authors would be happy to see this go into the base NSH spec, but we don't think you can simply define the value in the IANA section without saying what it means. So some additional text would be needed as well (presumably culled from the draft).
[DD] Except we have no explanation for handling MPLS, Ethernet, IPv4, or IPv6. Only the values are defined in each case. Presumably the handling of Empty will be as self-evident as the others...

As to your point...

Did I miss your point?
[DD] I think I was trying to make the point that various statements about metadata and OAM should not be defined specifically for "empty" protocol. When each of these things are given treatment for MPLS, IP and Ethernet packets, whatever is said should apply to Empty as well.
[DD] Also, as far as I can tell, even these concepts of per-flow or per-path metadata are absent from the NSH draft. 

Cheers,
Adrian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 23 Jan 2017 02:07:27 -0500

Speaking as a participant, I rather like Adrian's description.
In particular, his last bullet covers a necessary case.  if an SF 
receives an NSH packet with a next protocol that it "knows" but does not 
actually support, then it has to drop the packet.  (For example, an SF 
which expects an IP packet, and receives an Ethernet packet.  of the 
reverse.)  Thus, dropping packets at SF which need to process content, 
but which do not understand the next protocol field seems to me to be 
quite appropriate.

As Adrian notes, if the SF is defined to pass on unknown next protocols, 
then passing on the packet is fine.

Yours,
Joel

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 23 Jan 2017 18:13:36 -0000

So probably a way forward is...

- We continue to work on the NSH draft and polish it as needed
   (e.g., describing how to handle unknown values)
- If that subsumes all of draft-farrel-sfc-convent that will be 
   fine according to the authors
- While this is going on, we will continue to maintain
   draft-farrel-sfc-convent, stripping text that makes it into the
   NSH draft, and fixing any issues we fine.

Depending on how things pan out, the chairs may find us enthusiastic about
getting WG adoption for our draft.

Cheers,
Adrian

> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: 23 January 2017 07:07
> To: Dave Dolson; [email-masked]
> Cc: [email-masked]
> Subject: Re: [sfc] SFC with next protocol = "None"
> 
> > You make some good points. I'm still left with the impression that *some*
> things you say should make their way into the NSH draft.
> > Please see inline [DD]
> >
> > I should say that I don't feel strongly about anything I've said; rather,
I'm
> exploring questions that occurred to me while reading your draft.
> >
> > -Dave
> >
> > I *do* agree that for implementations that don't support "None" there will
be
> no distinction between "None" and "Unsupported"
> >
> >> document, and clarify forwarding behavior to support the ideas in your
section
> 4
> > Like I said, the authors would be happy to see this go into the base NSH
spec,
> but we don't think you can simply define the value in the IANA section without
> saying what it means. So some additional text would be needed as well
> (presumably culled from the draft).
> > [DD] Except we have no explanation for handling MPLS, Ethernet, IPv4, or
IPv6.
> Only the values are defined in each case. Presumably the handling of Empty
will
> be as self-evident as the others...
> >
> > I keep hearing "We have to get on and publish the NSH spec" and I didn't
want
> to suggest changes that would only cause further delay.
> >
> > As to your point...
> >
> > I'm not sure that the draft describes semantics of metadata. It does talk
about
> the scope of the metadata (per SFP, per flow, per packet) and if this is what
you
> mean, then all I can say is that the whole concept of metadata may be a little
> under-specified.
> >
> > You could be referring to two places where we make observations about the
> content of metadata. The first is where we say that if you want to support
per-
> flow metadata in an NSH packet with Next Protocol = "None" the metadata will
> need to indicate which flow the metadata applies to. I believe this to be
self-
> evident. The second case is where we say that metadata could contain OAM.
> You're correct that this has not been stated anywhere, but it is also
"self-evident"
> from the current definition of the NSH.
> >
> > Did I miss your point?
> > [DD] I think I was trying to make the point that various statements about
> metadata and OAM should not be defined specifically for "empty" protocol.
> When each of these things are given treatment for MPLS, IP and Ethernet
> packets, whatever is said should apply to Empty as well.