Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt

[Dave Dolson <[e-mail]>]

Paul,
Are you unhappy with the metadata constraints I suggested below?
Perhaps qualified by "In the absence of out-of-band configuration..." ?

I believe that the schemes proposed in these drafts satisfy the constraints:
- draft-sfc-nsh-dc-allocation-4, 
- draft-napper-sfc-nsh-broadband-allocation-00 

(I thought there were more allocation schemes, but I guess they expired.)

I'll update it here:

   In the absence of out-of-band configuration to indicate otherwise,
   metadata used in NSH headers must meet the condition that
   a transport-layer-stateful Service Function can save away
   metadata values that it has witnessed.  An injected packet can
   therefore be assigned a clone of metadata taken from an earlier
   packet going in the same direction.  For example, a Service Function
   can send a TCP packet using metadata cloned from another TCP packet
   of the same connection and direction.
 
   Note that the Service Function need not know the meaning of the
   metadata; it just needs to know it is safe to clone in this manner.


-Dave



-----Original Message-----
From: Paul Quinn (paulq) [mailto:[e-mail]] 
Sent: Tuesday, April 12, 2016 9:03 PM
To: Ron Parker
Cc: Dave Dolson; Thomas Narten; [e-mail]
Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt

Ron, Dave,

The draft describes the metadata as opaque, and really NSH is just the envelop for it.  The same can be said for the TLV as well -- there's no spec in NSH, not should there be.  In both cases, the metadata can/should/(must?) be define in auxiliary drafts.  There are several drafts re: metadata that can be discussed and eventually standardized.  It also bears mentioning that the control plane, today in opensource, defines the type 1 semantics.  That schemes works well, and mixed implementations can play together.

So, perhaps the best way forward:

1.  Agree on the envelop and the use of that envelop
2.  As a WG, adopt --> standardize the opaque data, and the TLVs
3.  As a WG, work on more detailed of use of the control plane to, when needed, define semantics

Thoughts?

Thanks,
Paul


> On Apr 12, 2016, at 3:41 PM, Ron Parker <[e-mail]> wrote:
> 
> Dave,
> 
> I, too, have raised this issue on the thread.   I think you hit the nail on the head regarding interoperability, which is the primary reason for having a specification, at all.    My mental model for the type-1 mandatory context headers is that of a composite 16-byte locally defined scratchpad.   I struggle with having its definition completely undefined in the document and still making it mandatory.    
> 
> Much of the justification offered has been to be friendly to hardware.   Surely hardware needs to know the exact format and meaning of these 16 bytes.
> 
>   Ron
> 
> 
> 
> 
> -----Original Message-----
> From: sfc [mailto:[e-mail]] On Behalf Of Dave Dolson
> Sent: Tuesday, April 12, 2016 3:29 PM
> To: Thomas Narten <[e-mail]>; [e-mail]
> Subject: Re: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt
> 
> 
> The NSH draft indicates that MD-Type 1 MUST be supported, yet the Mandatory Context Header fields are not defined in the document.
> 
> Issues with metadata semantics have been raised various times on this list and in drafts, and never satisfactorily addressed.
> Examples:
> https://tools.ietf.org/html/draft-vallamkonda-sfc-metadata-model-00.txt
> https://www.ietf.org/archive/id/draft-wang-sfc-md-type-issues-00.txt
> https://www.ietf.org/archive/id/draft-penno-sfc-packet-02.txt
> https://mailarchive.ietf.org/arch/msg/sfc/2YvBakDgJ_hjY-BGvgWdcTTUDIs
> 
> 
> So I don't feel this draft sufficiently explains the MD-Type 1 metadata well enough to explain how one can make an interoperable implementation.
> 
> The draft references metadata allocation drafts, but they have not been adopted yet, so (as I understand it) these "works in progress" cannot support draft-ietf-sfc-nsh.
> 
> 
> I think it might be acceptable to say that the metadata must be undirectionally clonable (or better phrase).
> In other words,
> 
>   Metadata used in NSH headers must been the condition that
>   a transport-layer-stateful Service Function can save away
>   metadata values that it has witnessed.  An injected packet can
>   therefore be assigned a clone of metadata taken from an earlier
>   packet going in the same direction.  For example, a Service Function
>   can send a TCP packet using metadata cloned from another TCP packet
>   of the same connection and direction.
> 
>   Note that the Service Function need not know the meaning of the
>   metadata; it just needs to know it is safe to clone in this manner.
> 
> 
> 
> Another alternative would be to import one of the metadata allocation schemes into this draft as MD-Type 1, and allow IANA to allocate MD-types for other schemes.
> 
> 
> 
> -Dave
> 
> 
> 
> 
> -----Original Message-----
> From: sfc [mailto:[e-mail]] On Behalf Of Thomas Narten
> Sent: Wednesday, March 30, 2016 10:48 PM
> To: [e-mail]
> Subject: [sfc] WG last call for draft-ietf-sfc-nsh-04.txt
> 
> Dear WG:
> 
> This note begins a WG last call on draft-ietf-sfc-nsh-04.txt (https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/).
> 
> The editors of the NSH document have indicated that they have addressed all known comments and that there are no open issues with the current version of the document.
> 
> Substantive comments to the list please, editorial comments can go directly to the document editors.
> 
> We'll also get a brief update from the editors at next week's meeting. If there are any remaining issues with the document, raising them before the meeting would be especially helpful.
> 
> For the chairs,
> Thomas
> 
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc
> 
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc
> 
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc