IETF97 Seoul SFC Agenda - Monday 11/14/16 9:30-12:00 Total time: 2.5 hours Meeting starting. 00:00 (9:30) Introduction (WG-chairs) - [5 minutes] Agenda bashing, note-well, document status, known document plans, interim meeting (WG-chairs) - [5 minutes] Note well applies. Agenda bashing. Kent Leung/Cisco: Asking to switch the order of presentations. Joel Halpern: Yes. Joel: Summary of document status - we need more reviews and please raise new issues. Joel: Greg Mirsky has already volunteered for a new coauthor on the OAM draft. Joel: Other potential authors and contributors are solicited Joel: Physical interim is planned around January timeframe, likely East coast. 00:05 (9:35) OpenDaylight Control Plane Implementation (Remote presenter + open-mic) - [20 minutes] - OpenDaylight Control Plane Implementation (Brady Allen Johnson) - [20 minutes] Brady Johnson/Ericsson presenting remotely. An overview of implementation details. Tal Mizrahi/Marvell: How is NSH configured - do you use Netconf, or something else? Brady: It is configured using OpenFlow. Tal: which version? Brady: 1.4 Kent Leung/Cisco: The last SF seems to extend the path to the egress? This seems to be different from the SFC architecture. Brady: Yes, and that was mentioned on the first slide. Brady: It is the last SFF that removes the encapsulation. There seems to be some ambiguity in the specification - either the last SFF, or any (last SFC boundary node). Kent Leung/Cisco: There is a draft on packet generation that addresses this. draft-penno-sfc-packet (expired) --should be refreshed Stewart Bryant: Are we discussing the artefact of the fundamental SFC architecture, or an artefact of the specific implementation? Joel: It discussed the implementation. Brady, if you could send a mail to the list that describes these deviations? Stewart: If you change this operation, it will end up in random packets wandering the network. 00:25 (9:55) Service Function Chaining Metadata Type 1 and Type 2 (Presenter + open-mic) - [20 minutes] - Service Function Chaining Metadata Type 1 and Type 2 - (Behcet Sarikaya) - [20 minutes] - https://tools.ietf.org/html/draft-sarikaya-sfc-metadatat1t2-00 Behcet presenting. Dean Bogdanovic/Volta Networks: How is your draft different in regards with source and destination selection? Behcet: My draft is about classification, that is a different topic. Lucy Yong/Huawei: Implementation and backward compatibility concerns - this seems to require control plane involvement to pass this information around (for type 1). Also, our recent proposed additional text to NSH and control plane documents address these concerns. Joel: There is a distinction between the processing and specifying the semantics. An example of subscriber id. Processing may use RADIUS, Diameter, etc. But the semantics needs to be specified. We need to be clear which part is to be standardized. Praveen Muley/Nokia: There are different types of use cases and processing the metadata is specific to the use cases. 3GPP example - there are many use cases that would need additional information about the details. Use cases should be defined and controlled by the relevant standard bodies and not done here - that will be more scalable and realistic. Behcet: What about interoperability? Praveen: Interoperability relies on the common components. Kent Leung: I would agree. TLV approach for type 2 seems to be sufficient. It is possible to add 3GPP relevant attributes into that structure. For type 1 I do not see why we should add in another registry as it's defined in draft. How to synchronize it then? David Dolson/Sandvine: If we had only one format for type 1 then it would be OK. But we have more, and interoperability is at question. Behcet: We have specific drafts for specific places in network. Lucy: Having a registry will make it easier to register new attributes. Lucy: Any use case is up to the implementation to determine how they want to use type 1. Behcet: It is possible to merge the drafts and call that a single registry. Kent Leung: Multiple type 1s is a separate discussion. My question is on the definition of the registry for type 1. There seems to be an overlap. Walter Haeffner/Vodafone: I recall type 1 was meant for silicon implementations and therefore it needed to be very precise. Joel: Out of time, please continue the discussion on the list. 00:45 (10:15) SFC Control Plane Components & Requirements (Presenter + open-mic) - [20 minutes] - SFC Control Plane Components & Requirements (David Dolson) - [20 minutes] - https://tools.ietf.org/html/draft-ietf-sfc-control-plane-08 David Dolson presenting. Joel: If you have raised questions earlier - please let us know on the list whether they got answered. Alia: I got routing directorate review for the document. There seem to be problems - it obscures instead of clarifying several aspects. The document was not seen as helpful. It is not clear whether we are discussing the requirements, or solutions. I am not comfortable sponsoring it at this time. David: We have defined interfaces in it. Do you believe the descriptions of interfaces are sufficiently detailed? Alia: It would be more helpful to describe the functional components - this piece does this and requires that. The document seems to obfuscate the interworking between the components. I encourage the WG to seriously question the description of those components. I am happy to request more reviews. Lucy: It is not necessary the requirements for component implementations. Alia: The document is very repetitive and confusing. Joel: We will work with the AD to resolution. 01:05 (10:35) SFC Security Design Team Update (Presenter + open-mic) - [10 minutes] - SFC Security Design Team update (Daniel Migault) - [10 minutes] - https://tools.ietf.org/html/draft-mglt-sfc-security-environment-req-02 Daniel Migault presenting. Dean Bogdanovic: You mentioned that user cannot control the control plane traffic. Daniel: No. The entity defining the SFC control plane have little control on what the user can send. Dean: As a user I have my defined data path, and I want to control the path that my packets take. You can give access to services according to authorization, but I should control the path taken within the authorization domain. Daniel: Are you thinking on a tenant as a user? Joel: That is a good question but we have no time, please take to the list. Joel: Chairs have a higher level question that we would like everyone to think about - is it a useful document? Do we need to provide more details on the specific ways or tools? Please do review the draft. 01:15 (10:45) Controlling Service Function Access to Network Service Header (Presenter + open-mic) - [10 minutes] - Controlling Service Function Access to Network Service Header (Victor Vu) - [10 minutes] - https://tools.ietf.org/html/draft-vu-sfc-sf-access-control-00 Victor Vu presenting. Joel: It might be helpful to think on the aspect that would require standardization vs the description of internal implementation aspects. Kent Leung: You are introducing a new logical function here - how and where does that fit in the SFC architecture? Victor: It can update the metadata. Kent: The SF will not see some metadata. How does that relate to SFC architecture? Could it be a function implemented as a helper of some kind? David Dolson: Do you assume that the metadata is constant for the flow? Victor: Yes. Joel: (some of the proposals in the draft assume that) David: Is that a reasonable assumption? Joel: It is not something that we have assumed today. 01:25 (10:55) BGP Control Plane for NSH SFC (Presenter + open-mic) - [20 minutes] - SFC Control Plane for NSH SFC (Adrian Farrel) - [20 minutes] - https://tools.ietf.org/html/draft-mackie-bess-nsh-bgp-control-plane-00 Adrian Farrel presenting. Adrian: [in the context of the BGP control plane] What is the status of SFC OAM? Joel: We need new authors, but the document is alive. Joel: It would help to identify what control plane requirements are being addressed by your document. Kent Leung: [on slide 9] How do you deal with statefull service functions? Adrian: If a SF is statefull, you MUST always go through the same instance. Therefore the controller has a good view of what functions are on what path. It needs to not offer a choice of paths in this case. Joel: Balancing needs to be flow stable in this case. Kent: There may be options for doing balancing in different ways. Robert Raszuk: Assume I have a SF over multiple paths. Is BGP the best way for propagating information like node resource utilization? Adrian: When you make a choice, you do that based on what a load is - and is your question whether BGP is the right tool for doing that? Unlikely. Joel: This draft doesn't require it. Adrian: How do you discover load? It is much more dynamic than a link load in a network. Has anyone got any ways of measuring and propagating those metrics? Lucy Yong/Huawei: Regarding looping - current architecture requires SFF not to forward a packet to another SFF to avoid looping. Adrian: I have trouble aligning that with a fact that SFF does not know where it received the packet from. Lucy: You introduce SF type. How is that type going to be discovered? Adrian: I do not care how SF knows its type - that is outside of scope. SFF knows that there is a SF instance with a particular type. Adrian: This does not require changes to dataplane. SFC Network Security Use Cases and NSH Allocation (Presenter + open-mic) - [10 minutes] - SFC Network Security Use Cases and NSH Allocation (Eric Wang) - [10 minutes] - https://tools.ietf.org/html/draft-wang-sfc-ns-use-cases-02 01:45 (11:15) Recieve-only Service Function (Presenter + open-mic) - [10 minutes] - Receive-only Service Function (Eric Wang) - [10 minutes] - https://tools.ietf.org/html/draft-wang-sfc-receive-only-01 Kent Leung presenting. No questions. 02:05 (11:35) RADIUS Attributes for NSH (Presenter + open-mic) - [10 minutes] - RADIUS Attributes for NSH (Roberta Maglione) - [10 minutes] - https://tools.ietf.org/html/draft-maglione-sfc-nsh-radius-01 Roberta presenting. Roberta: Is this work relevant to WG? Joel: If the WG decides that this is relevant work we will coordinate with radext WG to synchronize on the RADIUS extensions. Praveen Muley/Nokia: Have you considered looking into different attributes for uplink and downlink? Roberta: Not yet but we can discuss that. 01:55 (11:25) Network Service Header KPI Stamping (Presenter + open-mic) - [10 minutes] - Network Service Header KPI Stamping (Rory Browne) - [10 minutes] - https://tools.ietf.org/html/draft-browne-sfc-nsh-kpi-stamp-00 Behcet: This draft defines some more TLVs which are not covered in my draft. Rory presenting remotely. Lucy Yong: This seems to be useful way of using metadata. Especially for the small set of traffic. Greg Mirsky: Why do you stress that this is not OAM? There is passive and hybrid OAM too. Would encourage to look at the documents that have been discussed in Berlin and also into overlay OAM documents. 02:25 (11:55) Closing (WG-chairs) - [5 minutes] Joel: please bring discussions to the list. Meeting concluded.