Minutes interim-2017-sfc-01: Tue 11:00
minutes-interim-2017-sfc-01-201701171100-00

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.