Attendees: Adrian Farrell; Alia Atlas; Andrew G. Malis; Dave Dolson; Don Fedyk; Eric C Rosen; Ignas Bagdoues; Jim Guichard; Joel M. Halpern; Lucy Yong; Mohamed Boucadair; Paul Quinn; Ron Parker; Tal Mizrahl. Remote Attendees: Greg Mirsky; John Drake; Linda Dunbar; Behcet Sarikaya; Igor Bryskin; Roberta Maglione; Xufeng Liu. A. NSH document discussion: WG chairs have collected several changes that have already been agreed upon by the WG. These changes have been communicated to the NSH document editors (as well as email to the WG list and updates made to the associated tickets) and will be reflected in an upcoming version of the document. WG chairs have asked the editors to publish this updated version of the document ASAP so that it can be used as the baseline for adding further changes agreed upon at the interim meeting (assuming WG consensus is reached). C bit discussion: Extensive discussion on the c bit in NSH base header and c bit in TLV. • Summary: Agreement that the value in the c-bit was in forcing packets to be dropped by SFF who would otherwise ignore the metadata. The cost is that all SFF along the path would need to examine the metadata. As we have no use case mandating such a discard, we decided that the cost was not something we needed, and agreed to drop the bit. • Room consensus: 1. Remove the c bit from the NSH base header, returning the bit to “reserved” status .1.1. Section 3.2 figure and associated c bit text .1.2. Section 3.4 figure .1.3. Section 3.5 figure 2. Remove the c bit from the variable-length metadata header, making the Type an 8-bit field. .2.1. Section 3.5.1 figure and associated text 3. Remove text “and where needed to mark that data as critical” from section 9 ‘Security Considerations’ 4. Remove c bit from section 12.2.1 • Dave Dolson will send a proposal about removing c bit in the NSH base header and c bit in TLV to the SFC WG mailing list. NSH base header length discussion: Discussion on the length field within the NSH base header. • Current text in section 3.2 of the NSH document has an issue. The last sentence of the length description currently reads “The length field indicates the “end” of NSH and where the original packet/frame begins”. Discussion around hierarchical NSH showed that there are cases where the end of the NSH base header and context headers may not be the beginning of the original packet/frame. Therefore a textual change is necessary to make it clear that the length field indicates the beginning of the packet/frame of the next protocol reflected in the NSH base header. • WG chairs will send a proposal to the SFC WG mailing list to get consensus on the necessary textural changes to the NSH document. NSH base header discussion: Discussion around which of the NSH headers are mandatory and which are not. • Current text in section 3.1 for the NSH header format does not indicate which of the headers are mandatory which is confusing and a request was made to clarify this within the document. • Adrian Farrel will send a proposal to the SFC WG mailing list for clarifying changes to section 3.1 of the NSH document. SFC Loop Detection discussion: • Lucy presented SFF loop prevention proposal. Adrian raised another loop case: reclassification may cause a loop too. Should use one solution to address all loops at the service plane level. • SI can be used for some loop detection; should not change that. Just need a solution to detect SFF loop and reclassify loop cases. • Discussed various possible solutions. Proposal to use 6 reserved bits from the NSH base header for TTL, and allocate some bits from MD type field as reserved field. • Use of MD type field as TTL was raised. Not adopted. • Some concerns were raised about introducing the TTL field, and how it will interoperate with pre-standard implementations. Two proposals that can potentially mitigate these concerns were discussed: 1. Make the TTL optional. 2. Define a new version number. The room consensus was that both proposals are not a good idea. • Backward compatibility concern may be described in NSH appendix. NSH is not RFC yet, BC is a bit concern but should not be a stopper. • Consider TTL usage for OAM purpose. Copy the TTL value is bad. Consider other solution. • After much discussion, the room settled on a two part proposal. 1. Use the six currently reserved flag bits as a 6 bit TTL field. Exact processing rules need to be agreed by the WG, but roughly “decrement everywhere”. (Issues such as count up or count down, do SFF decrement on every reception, etc., to be discussed and resolved using a specific proposal.) 2. The upper bits (number to be determined) to be reserved for flag bits. The interaction of this with implementations of the earlier specification to be discussed in a document appendix. • It is not clear when receiving a NSH packet, if SF does not support the MD type, what to do. • WG Chairs and document editors to go through NSH document to clarify the process rules for SFC component to receive an NSH packet, including SFF, SF, reclassifier, especially if a field value is not understood. SI value process discussion: • Make this explicitly in NSH “SI decremented by 1” • Handling non-contiguous decrement value, SFF set the value based on forwarding table, etc.; no consensus on this suggestion. Other discussion results are reflected in the action items. Summary of action Items for NSH document: 1. Proposal to remove c bit in the NSH base header and c bit in TLV. AI: Dave Dolson to send proposal to the SFC WG mailing list (Status: Done). 2. Length in NSH base header text correction. AI: WG chairs to send proposal to the SFC WG mailing list (Status: Open). 3. Clarify which NSH headers are mandatory. AI: Adrian Farrel to send proposal to the SFC WG mailing list (Status: Done). 4. SFC loop prevention solution. Proposal for 6 reserved bits for TTL, take some bits (2 or 3?) from the MD type field and make them reserved bits. AI: WG chairs (or someone else) to send proposal to the SFC WG mailing list (Status: Open) 5. “SI decremented by 1” explicitly in the NSH document. AI: WG chairs to send mail to the SFC WG mailing list with proposal (Status: Open). 6. Make MD#2 with length 2 mandatory, and MD#2 length > 2 is optional. AI: Adrian Farrel to send proposal to the SFC WG mailing list (Status: Open). 7. Next protocol list (IANA registry) needs to align with other WGs such as NVO3 (will be chair/AD’s work) 8. Next protocol can have a NULL value, Adrian and Lucy will have a separate draft to specify the use of NULL value. AI: Adrian/Lucy to publish draft (Status: Done). 9. Correction on Registry for MD Class: MD class code point 0 for IETF, 1-xxxx for IETF review. All IETF specified types will use IETF code point. If 3gpp define a set of types and ask code point from IETF; IETF will allocate code point from IETF review range. 10. IANA needs a TLV type registry for MD class 0, i.e. IETF. Should this registry be specified in NSH document, or nsh-tlv document? Go on mailing for consensus. 11. Clarify all process rules for SFC component to receive a NSH packet, including SFF, SF, reclassifier, especially the rule if a field value in NSH header is not understood. AI: WG chairs/NSH document editors to review NSH document for clarity (Status: Open). 12. Some changes for NSH document for MD 1&2 are listed in MD discussion (below) B. Security Environment document discussion: Discussion centered on draft-mglt-sfc-security-environment-req-02 document and whether it satisfies the needs of the SFC WG. • The document needs to tailor for SFC specific environmental security, not general security requirements or SFC protocol security requirements. It can reference some existing security documents for non-SFC part such as RFC4778 and RFC5949. • Room consensus: anything that is SFC specific protocol security requirement should be removed from draft-mglt-sfc-security-environment-req. • Discussion on whether the WG needs a separate SFC protocol security requirements document. An expired document exists (draft-reddy-sfc-nsh-security-req) and the room discussed whether that document should be resurrected or should the protocol specific requirements be folded into the NSH document. • Room agreement to move the relevant portions of this document to specific documents where it applies. Then to re-examine the remainder to see if there is a useful document for further work. Summary of action items for security discussion: 1. Chairs to email the SFC WG mailing list to get consensus on whether a standalone SFC protocol security requirements document should be worked on or should said requirements be folded into the relevant individual documents. AI: WG chairs (Status: Open). 2. Security considerations in NSH document should fix citation issue: [SFC security requirements] has no reference and [nsh-sec] is expired. AI: NSH document editors to fix (Status: Open). C. OAM discussion: Discussion centered on how to move OAM work forward in the SFC WG and how to align with the common OAM approach being worked in NVO3. • Seek common approach of OAM for overlay. NVO3 support this approach. • Value to support both In-situ, and conventional OAM but focus first on conventional OAM. • Need to specify OAM requirement first, not the solution. • Priority: Finishing NSH is important to WG. Get basic OAM work first. • O bit, next protocol, metadata are all related to OAM operation. Regardless what OAM solution is adopted eventually, checking o bit in base header gives the great benefit for NSH moving ahead without depending on any OAM approach, in which the worst case is to have some redundant process for OAM, e.g. check O bit and next protocol. • Room + plus Greg Mirsky consensus: O bit to indicate OAM message exists on NSH packet. NSH does not need to specify any OAM function except O bit. Take the expired OAM framework draft (draft-ietf-sfc-oam-framework-01) and use it to develop the OAM requirements. This document has been dormant for a while and was previously adopted as a WG document but with no movement since adoption. Summary of action items from OAM discussion: 1. WG chairs will chase some folks to work on OAM framework draft. (No change to NSH draft). AI: WG chairs (Status: Open) D. Control plane requirements document discussion: Discussion on the current control plane requirements document draft-ietf-sfc-control-plane-08. • Concerns have been expressed from several quarters that attempting to use this document to guide protocol development (or implementation) of control functionality is quite challenging. • This led to discussion of the target audience and purpose of the document. • Discussion of what is actually need regarding the control plane requirements for current WG work, for future expected WG work, for protocol designers in other working groups, for implementers, and for readers in the future. And how to provide the needed information. • Without this document, will it cause interoperability concerns? Yes, the control plane may contain multiple protocols, BGP is only one of them. Concern is that we don’t know what features each protocol should cover. Grouping will help. • Interface Information must be provided to define interoperable interfaces. This does not mean that a full data model is needed. • Current document may be limited by WG charter. • It is clear that there is work to be done here. However not clear what to be done yet. Need some regrouping the requirements to make more useful for the control plane development? • Chair: question to room: will SFC arch and NSH doc. be sufficient for SFC control plane implementation? If yes, we do not need to work on control plane requirements. No consensus on chair’s question. E. MD-1 discussion • Control plane needs to inform SFC components the MD-1 format per SPI. • Publishing MD-1 formats for common use case is useful. • Lucy presented two possible ways for the control plane to inform the data plane elements of the MD#1 format. WG will not mandate a particular way. • Discussion of whether a registry of MD-1 formats would be useful. Room concluded that there is no need to create a registry and assign code point for each published MD-1 format now. In future a control plane protocol may request a registry for identify individual format for the protocol to use. • SFC allows changing MD-1 format to MD-2 on a SFP or vice versa. Current document has not yet made this clear. • A MD-1 format is not relevant to NSH protocol. However, it was asked if the MD-1 format may change along the SFP. NSH doc. needs to clarify MD-1 format granularity. The WG needs to decide what it wants in this regard. Room consensus: • Publish MD-1 formats for common use cases as informational RFCs. • Allow changing MD-1 format to MD-2 in a SFP or vice versa. • Get WG consensus the granularity of MD-1 format, 1) per SPI; 2) per SPI and hop; etc. (current is per SPI). Once reach consensus, update NSH doc in section 3.4, Section 4, and figure 8 to reflect the consensus. The MD-1 granularity will clarify what control plane and SFC components can be. Action items: 1. NSH doc. clarifies that changing MD-1 format to MD-2 in or a SFP or vice versa is allowed. 1. Update NSH to reflect the WG consensus on MD-1 granularity (see MD-1 room consensus). F. MD-2 discussion • SFC needs to specify the processing rules but not all processes. I.e. the TLV definitions need to provide enough meaning for the particular TLVs that entities can make use of them. But internal or back end processing logic is not for SFC or an SFC Metadata TLV registry to mandate. • It was observed that the current common TLV document does not have enough description for some of the TLVs. Folks should provide comments to the WG on where they would like to see more elaboration. Preferably with proposed text. • It was also discussed that some TLVs are better explained in their own documents. Particularly if the document exists for another reason, or if lengthy explanation is useful for some TLV (or set of TLVs. After discussion, it was agreed that the common base document can and should be used for TLVs we currently know of that need short descriptions. TLVs which fit naturally in some other document can and should be defined in those documents. • For example, the documents defining MD-1 formats can also define a MD-2 Type code for carrying the same block of information with the same structure. • Need to consider a way for vendor to create own MD-1 format, preparatory one. This is not clearly covered now. Room Consensus: • The TLVs with short explanations belong to common TLV doc.; other doc. may define the TLV needing more semantics for a use case. In particular, there is no point in an entry in the common document whose only text is “see WFC document X for structure and meaning of this TLV.” In that case, document X should reserve the type code. Action item: 1. Editors to remove inappropriate entries 2. WG to work out mechanism for vendors to create their own MD-2 type codes. G. Transport related discussion • SFC arch are transport agnostic. However, SFC architecture has some requirements on transport behavior such as ECMP, data plane length, etc. • SFC arch made some assumption on transport. We should document these assumptions and requirements. Transport requirement work should be done in this WG. Homing for transport solution work to be resolved on a case by case basis, with care to avoid overload. Room Consensus: • Chairs needs to work with other WG on Transport requirement and behavior. Action Item: 1. SFC WG work on transport requirement document.