An MPLS-Based Forwarding Plane for Service Function Chaining
draft-ietf-mpls-sfc-07

[Ballot comment]
Thanks for addressing my DISCUSS. Original COMMENT below.

= Section 4.5 =

OLD
The application of SR to SFC was considered in early versions of the
  SR architecture [RFC8402] and the MPLS-SR specification
  [I-D.ietf-spring-segment-routing-mpls], but has since been moved out
  of those documents.

NEW
The application of SR to SFC was considered in early versions of the
  SR architecture [RFC8402] and the MPLS-SR specification
  [I-D.ietf-spring-segment-routing-mpls], but was not ultimately adopted.

(I think this is about the ideas, not the organization of documents.)

[Ballot discuss]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D5624


I have what may be a simple question or a real interop problem, as
noted below. Hopefully it's the former and we can resolve it quickly.



DETAIL
S 13.
>        and defined in [RFC8300].
> 
>      Metadata:  The actual metadata formatted as described in whatever
>        document defines the metadata.  This field is end-padded with zero
>        to three octets of zeroes to take it up to a four octet boundary.
> 

What happens if the packet gets lost? Is there an ACK? How often
should I send it?

[Ballot comment]
S 12.1.
>          ---------------
> 
>                      Figure 4: The MPLS SFC Metadata Label
> 
>      The Metadata Label value is an index into a table of metadata that is
>      programmed into the network using in-band or out-of-band mechanisms.

You note below that the network needs to be secure. You should also
note that access to this table needs to be secure.

[Ballot discuss]
Thank you for this easy-to-read document!  The design is pretty elegant,
but I think there are a few places that remain insufficiently specified
so as to admit interoperable implementation.

In particular, I don't think the TTL-handling behavior for the SF Label
in the "label stacking" case is completely specified, though an
apparent typo in Section 7 (see COMMENT) makes it hard to tell what was
intended.

In Section 8, we see that:
  When an SFF receives a packet containing an MPLS label stack, it
  checks whether it is processing an {SFP, SI} label pair for label
  swapping or a {context label, SFI index} label pair for label
  stacking. [...]

What data source is consulted to make this check?  The control plane?
Is this distinction made on a per-node basis or a per-packet basis or
otherwise?  My first thought was that it's per-SFC-Context-Label, but
we're not guaranteed that those values will be interpretable
equivalently in the swapping or stacking usages, IIUC.

I also support Alissa's DISCUSS (and the secdir reviewer makes similar
comments).

[Ballot comment]
Am I supposed to assume that the control plane sufficiently informs
everyone whether they're an SFF, SFI, or neither?  (Or does any given
(virtual) device just inherently know?)

Abstract (and Introduction)

  Multiprotocol Label Switching (MPLS) is a widely deployed forwarding
  technology that uses labels placed in a packet in a label stack to
  identify the forwarding actions to be taken at each hop through a
  network.  Actions may include swapping or popping the labels as well,
  as using the labels to determine the next hop for forwarding the
  packet.  [...]

nit: no comma after "as well".

  This document describes how Service Function Chaining can be achieved
  in an MPLS network by means of a logical representation of the NSH in
  an MPLS label stack.  That is, the NSH is not used, but the fields of
  the NSH are mapped to fields in the MPLS label stack.  It does not
  deprecate or replace the NSH, but acknowledges that there may be a
  need for an interim deployment of SFC functionality in brownfield
  networks.

Am I supposed to read this as that the NSH is the way of the future, and
this mechanism is just a temporary interim measure?

Section 4.3

  It may be that a service function chain (as described in Section 4.1
  allows some leeway in the choice of service function instances along
  the chain.  However, it may be that a service classifier wishes to
  constrain the choice and this can be achieved using chain
  concatenation so that the first chain ends at the point of choice,

This does not give any motivation for why a classifier might wish to
constrain the choice.

Section 5

The decision to use the control plane to indicate "label stacking" vs.
"label swapping" semantics as opposed to an in-band signal seems to
create a new opportunity for misconfiguration and consequent service
misbehavior.  I suppose it's not appreciably worse than any other way to
configure the interpretation of the label field, though.

  S: The bottom of stack bit has its usual meaning in MPLS.  It MUST be
      clear in the SFC Context label stack entry and MAY be set in the
      SF label stack entry depending on whether the label is the bottom
      of stack.

I don't understand why this is only a MAY.

Section 6

      Under normal circumstances (with the exception of branching and
      reclassification - see [I-D.ietf-bess-nsh-bgp-control-plane]) the

The word "reclassification" does not appear in the indicated reference.

  The following processing rules apply to the TTL field of the SF label
  stack entry, and are derived from section 2.2 of [RFC8300]:

nit: we seem to capitalize "SF Label"

Section 7

It's a bit unusual, style-wise, to have Section 6 introduce new terms
for the SPI Label and SI Label that are specific to the swapping usage,
and then have Section 7 just reuse the nominally generic terms from
Section 5 as its own for the stacking usage.

  SFC Context Label:  The Label field of the SFC Context label stack
      entry contains a label that delivers SFC context.  This label may
      be used to indicate the SPI encoded as a 20 bit integer using the
      semantics of the SPI is exactly as defined in [RFC8300] and noting
      that in this case a system using MPLS representation of the
      logical NSH MUST NOT assign SPI values greater than 2^20 - 1 or
      less than 16.  This label may also be used to convey other SFC
      context-speific semantics such as indicating how to interpret the
      SF Label or how to forward the packet to the node that offers the
      SF.

This "may also be used" behavior seems rather under-specified.

  TTL:  The TTL fields in the SFC Context label stack entry SF label
      stack entry SHOULD be set to 1 as stated in Section 5, but MAY be
      set to larger values if the label indicated a forwarding operation
      towards the node that hosts the SF.

What is "SFC Context label stack entry SF label stack entry"?  It seems
like there's a missing word or something.  I note that section 5 defers
to here for the TTL of the SF Label and we are either not saying
anything or attempting to defer to Section 5, so this seems
under-specified.

Section 8

  o  If the current hop requires an {SFP, SI} and the next hop requires
      an {SFP, SI}, it selects an instance of the SF to be executed at
      the next hop, sets the SI label to the SI value of the next hop,
      and tunnels the packet to the SFF for that SFI.

nit: I know the default behavior is to use the same SFP value, but (1)
this should probably be stated explicitly, and (2) we've already talked
about branching/etc. that could cause it to change.

      *  If the top of the MPLS label stack contains a {context label,
        SFI label}, it tunnels the packet to the SFF indicated by the
        context label.

nit: probably best to use "new top" for consistency with the preceding
sub-bullet.

Section 12.1

  The SFC Metadata Label (as a set of three labels as indicated in
  Figure 4) may be present zero, one, or more times in an MPLS SFC
  packet.  For MPLS label swapping, the SFC Metadata Labels are placed
  immediately after the basic unit of MPLS label stack for SFC as shown
  in Figure 5.  For MPLS label stacking, the SFC Metadata Labels can be
  present zero, one, or more times and are placed at the bottom of the
  label stack as shown in Figure 6.

The "may be present zero, one, or more times" appears twice.
(I actually don't mind the internal redundancy of that phrase here, though,
since all three cases are potentially relevant.)

Section 12.2

  Metadata Type:  The type of the metadata present.  Values for this
      field are taken from the "MD Types" registry maintained by IANA
      and defined in [RFC8300].

The "MD Types" registry I'm finding in RFC 8300 is defined to hold
four-bit values; why do we need a 16-bit field to hold it here in the
TLV?  (I mean, "to keep the metadata itself aligned", sure, but having
12 reserved bits would do that, too.)

Section 15

I agree with the secdir reviewer that the "trusted" nature of the
classifier as a "trusted resource" could be further clarified.

                                                Where an SF is not
  encapsulation aware the encapsulation may be stripped by an SFC proxy

nit: "encapsulation-aware"

Thank you for the new text in the -05 prompted by the secdir review; it
is a huge improvement!
In addition to encryption, I'd probably also note that MPLS at present
doesn't provide any cryptographic integrity protection on the headers.

  o  The SFC-capable devices participating in an SFC system are
      responsible for verifying and protecting packets and their
      contents as well as providing other security capabilities that
      might be required in the particular system.

Do I recall correctly that we currently don't specify any mechanisms for
them to do so?  If so, we probably need to note that this is currently
in implementation-specific territory.

I'd also suggest
OLD:
  Thus, the security vulnerabilities are addressed (or should be
  addressed) in all the underlying technologies used by this design.
NEW:
  Thus, this design relies on the component underlying technologies to
  address the potential security vulnerabilities, and documents the
  necessary protections (or risk of their absence) above.  It does not
  include any native security mechanisms in-band with the MPLS
  encoding of the NSH functionality.
(since "are addressed (or should be addressed)" is rather wishy-washy
language).

  No known new security vulnerabilities are introduced by this design,

It's probably worth stating what the reference point for the comparison
is, just for clarity.  (I assume it's the RFC8300 NSH.)

Section 19.2

It seems that RFC 6790 needs to be a normative reference, since we are
RECOMMENDED to insert Entropy Labels.

[Ballot discuss]
Comparing the requirements in RFC 8300 Section 8.1 under "Single Domain Boundary" and the text in Section 15 of this document, it seems that the mechanism specified in this document is not subject to the same normative requirements as specified for the administrative boundaries of a network where MPLS is used as the transport encapsulation for NSH. What is the reasoning for that? I would have expected to see similar normative requirements here as in RFC 8300 Section 8.1.

[Ballot comment]
= Section 4.5 =

OLD
The application of SR to SFC was considered in early versions of the
  SR architecture [RFC8402] and the MPLS-SR specification
  [I-D.ietf-spring-segment-routing-mpls], but has since been moved out
  of those documents.

NEW
The application of SR to SFC was considered in early versions of the
  SR architecture [RFC8402] and the MPLS-SR specification
  [I-D.ietf-spring-segment-routing-mpls], but was not ultimately adopted.

(I think this is about the ideas, not the organization of documents.)

[Ballot comment]
One minor editorial comment:
The abstract is quite long (compared to usual RFC abstracts). I recommend to only have the last paragraph (or a slightly extended version of the last paragraph).

[Ballot comment]
Hello

thank you for this document.

I know I'm being too pernickety:
You say:
  o  An SFF MUST decrement the TTL by one each time it performs a
      forwarding lookup.
but in the examples you also say:
  b.  When the packet arrives at SFFa it strips any labels associated
      with the tunnel that runs from the classifier to SFFa.  SFFa
      examines the top labels and matches the SPI/SI to identify that
      the packet should be forwarded to SFa.  The packet is forwarded
      to SFa unmodified.
and
  d.  SFFa modifies the SI in the lower label stack entry (to 254) and
      uses the SPI/SI to look up the forwarding instructions.

It could look as two forwarding lookup, which, according to the requirement, could lead to two TTL decrements.
I do read in step b that the packet is forwarded unmodified, and read in Section 6 "The TTL in SF label stack entry is decremented once for each forwarding hop in the SFP"
but still I wonder if some clarification wouldn't be beneficial.


nits:
  TTL:  The TTL fields in the SFC Context label stack entry SF label
      stack entry SHOULD be set to 1 as stated in Section 5,
Do you mean: SFC Context label stack entry *and* SF label stack entry ?

s/document)./document./

[Ballot comment]
Apologies, I intended to finish reviewing this, but ran out of time (and have an early flight tomorrow). What I read all seemed fine, and I'm balloting NoObj.

I do have 2 tiny nits:
Abstract:
"Actions may include swapping or popping the labels as well, as using the labels" -- the comma seems superfluous / wrong.

I think perhaps "NSH MUST NOT assign SPI values greater than (1048575)  2^20 - 1 or less than 16." -- I'm concerned that people might be lazy and not everyone can do 2^20 -1 in their head.

[Ballot comment]
Thank you for a very clear document!

I think that the only NSH functionality not included in this document is the O bit (OAM packet).  I know that, even in rfc8300, the operation (beyond setting the bit) is not defined...and that work is still in progress in the SFC WG.  However, given that this document describes a "logical representation of the NSH", I think it is necessary to point out why the coverage is not complete.  In looking through the mail archive, I like the thoughts posted by one of the authors [1] and would like to see something like that reflected in the document.

[1] https://mailarchive.ietf.org/arch/msg/mpls/b9Duw-9ShdCrIRyis3TOJWw-_pw


nits:

s/(as described in Section 4.1/(as described in Section 4.1)

s/(see [I-D.ietf-bess-nsh-bgp-control-plane]/(see [I-D.ietf-bess-nsh-bgp-control-plane])

s/TC:  The TC bits have no meaning./TC:  The TC bits have no meaning in this case.

s/to determine to which SFF or instance of an SF (an SFI) to deliver the packet./to determine which SFF or instance of an SF (an SFI) to deliver the packet to.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-mpls-sfc-04. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Extended Special-Purpose MPLS Label Values registry on the Special-Purpose Multiprotocol Label Switching (MPLS) Label Values registry page located at:

https://www.iana.org/assignments/mpls-label-values/

two new values are to be registered as follows:

Value: [ TBD-at-Registration ]
Description: Metadata Label Indicator (MLI)
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: Metadata Present Indicator (MPI)
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-01-31):

From: The IESG
To: IETF-Announce
CC: mpls@ietf.org, db3546@att.com, mpls-chairs@ietf.org, Loa Andersson , draft-ietf-mpls-sfc@ietf.org, loa@pi.nu
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (An MPLS-Based Forwarding Plane for Service Function Chaining) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document: - 'An MPLS-Based Forwarding Plane
for Service Function Chaining'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-01-31. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  Service Function Chaining (SFC) is the process of directing packets
  through a network so that they can be acted on by an ordered set of
  abstract service functions before being delivered to the intended
  destination.  An architecture for SFC is defined in RFC7665.

  The Network Service Header (NSH) can be inserted into packets to
  steer them along a specific path to realize a Service Function Chain.

  Multiprotocol Label Switching (MPLS) is a widely deployed forwarding
  technology that uses labels placed in a packet in a label stack to
  identify the forwarding actions to be taken at each hop through a
  network.  Actions may include swapping or popping the labels as well,
  as using the labels to determine the next hop for forwarding the
  packet.  Labels may also be used to establish the context under which
  the packet is forwarded.

  This document describes how Service Function Chaining can be achieved
  in an MPLS network by means of a logical representation of the NSH in
  an MPLS label stack.  It does not deprecate or replace the NSH, but
  acknowledges that there may be a need for an interim deployment of
  SFC functionality in brownfield networks.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mpls-sfc/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-mpls-sfc/ballot/


No IPR declarations have been submitted directly on this I-D.

                The MPLS working group requests that
                        draft-ietf-mpls-sfc
              is published as an RFC on the Standards Track


(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  We request that draft-ietf-mpls-sfc is published as an Proposed
  Standard.
  This is the correct RFC type, since the document specifies new
  protocol, new protocol elements and assigns code points from a
  Standard Tracks registry.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document describes how Service Function Chaining can be achieved
  in an MPLS network by means of a logical representation of the NSH in
  an MPLS label stack.  It does not deprecate or replace the NSH, but
  acknowledges that there may be a need for an interim deployment of
  SFC functionality in brownfield networks.

Working Group Summary

  The processing of this document have been very smooth and the
  support from the working group is strong.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

    We do not currently have any definite information on existing
    implementations, an Implementations poll has been started and
    the write-up will be updated as soon as we get new information.

    There has been indications from vendors that they intednd to
    implement this specification.

    We also have a strong interest from operators to have this
    implemented.

    No special types of reviews is necessary.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

    Loa Andersson is the Document Shepherd.
    Deborah Brungard is the Responsible Area Director

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

    The Document Shepherd has reviewed this document prior to the
    working group adoption poll, and prior to working group last
    call.

    The document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

    No such concerns!

    Throughout the lifetime of the document the SFC working  group
    has been informed about solution and changes in the document.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

    No such reviews are needed.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

    No such concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

    All the co-authors and contributors has stated on the mailing
    list that they are unaware of any IPRs that relates to this
    document.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

    There are no IPR disclosures against this document.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

    The working group strongly support this document, it is a
    document that is necessary to make SFC work in an MPLS network.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summaries the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

    No such threats.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

    The document passes the nits tool clean.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

    No such reviews necessary.

(13) Have all references within this document been identified as
either normative or informative?

    All the references has been correctly been identified as
    normative or informative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

    All normative references are to existing standard tracks RFCs.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

    No downward references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

    The publication of this document will not change the status of
    any RFC.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

    Since this is the first time we allocated Special Purpose Labels
    from the extended range, the IANA section has been of particular
    interst for the Document Shepherd.

    No new IANA registries are created by this document.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

    No new IANA registries are created by this document.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

    No such reviews necessary.