Minutes IETF97: sfc
minutes-97-sfc-01

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.