Subject: [sfc] questions about the "draft-farrel-sfc-convent" (was RE: SFC with next protocol = "None"

From: Linda Dunbar <[email-masked]>
Date: Tue, 24 Jan 2017 19:46:22 +0000

Adrian, 

The " draft-farrel-sfc-convent" allows metadata to be exchanged without any payload. By doing so, those metadata can achieve the tasks traditionally done by the IPPM , such as TWAMP. I think it is a great idea. 
As many vendors have implemented TWAMP, possible to adopt the similar control mechanisms specified by RFC5357?

Your Section 5.2 says "the identity of the flow would need to be carried in the metadata". 

Even with empty payload, does the packet with the metadata still have the same IP header? 
Then, each packet header itself can identify the flow. Why need the "flow identity" to be carried in the metadata? 

Linda 

Flow is not a concrete definition. what does "identity of the flow" mean? why need to carried by the 
-----Original Message-----
From: sfc [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: 2017年1月23日 12:14
To: 'Joel M. Halpern' <[email-masked]>; 'Dave Dolson' <[email-masked]>
Cc: [email-masked]
Subject: Re: [sfc] SFC with next protocol = "None"

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

> -----Original Message-----
> 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"
> 
> 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
> 
> On 1/22/17 10:09 PM, Dave Dolson wrote:
> > 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,
> >
> >> 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).
> >
> > 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.
> > [DD] Point taken. Then is "Empty" as special case?
> >
> >
> > 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
> >
> > [DD] The net outcome being unknown next-header types are dropped
> somewhere?
> >
> >> "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).
> > [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...
> >
> > 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?
> > [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
> >
> >
> > _______________________________________________
> > sfc mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/sfc
> >

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 25 Jan 2017 14:49:17 -0000

Hi Linda,

> identity" to be carried in the metadata?

I think this is meaningless!

The payload protocol might not be IP.
The transport tunnel might not be IP.
What IP header are you talking about?

But, suppose the payload is IP, and the flow is defined by the normal 5-tuple and suppose the transport is IP.
The answer to your question is "no".
The transport IP address is used to reach the SFF (or to reach the SF, depending on where you are standing) so it does not match the flow.
And the whole point of Next Protocol "None" is to not have the payload packet.

So, in this case, *an* option is to include the 5-tuple in the metadata.
Other options might include placing the hash-result in the metadata, or using some other index that maps to the flow.

I believe:
1. Use cases for per-flow metadata are not well established (even if they might exist)
2. It is not the job of this document to define how to encode metadata for any use case (whether it is firmly defined or not). This document should just make some high-level observations.

Thanks,
Adrian