Re: [mpls] Opsdir last call review of draft-ietf-mpls-sfc-encapsulation-02

"Andrew G. Malis" <> Thu, 21 February 2019 18:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 37AA713108C; Thu, 21 Feb 2019 10:06:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Q0jiG1PUf4hm; Thu, 21 Feb 2019 10:06:36 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 37FD413108B; Thu, 21 Feb 2019 10:06:36 -0800 (PST)
Received: by with SMTP id s1so6406931qte.5; Thu, 21 Feb 2019 10:06:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5DU4A0cvGiFJKJgChxt6BFxScRZRP68oR2x9avJDc8s=; b=g3oI8bSYnqbVepOEeQYYV3TKwSlZhxF8IEai1gx9y/As8GdKibiWAXGuq3s6ioV5JY tjETYqRVXurBP/A7kj8xIHUD+/4UI8bm/V47/TwrLD6ErrSKPbAghf9oYdkkVRw8NoEQ Ow6KUXffdsSe5VRFUrBlYw2fTvbrHfwkpuGB82SxQ9vZ8qdjgPVMscx3E0hZbP8c6JOu Nu12sZBIKs2uuyE+Xi3lr2XmlBL11Yurpo1hzldVogDJ8uwFzJ10+tRt3Nc+p34NsxpI 7ohoNnQgF3+zsAuo4gwouVpNITUyEdzhISlMzOC7a4Gre8uYAsrk4dt0eOjxbWve6MsU iCFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5DU4A0cvGiFJKJgChxt6BFxScRZRP68oR2x9avJDc8s=; b=ayuxcEKWSVlAgxH1fOmyIOYDDgyrNdU3jYiGzpQ6xLPZAUAyXZ28+N4wDoNtMSPXct 8vOqEMX+sMoqdVUVq00JzyzoKVWvwcWOOb0Sh7mVP2zE23Y4u6ES9BSnmMuHmCfRh0x0 ei3bAV9ZcYCnuCS8zXajW7Q5GJy/k+B8k1l1cEQtiTaNm2K9aEHs/mhJTdEz+OWni4HD kqIBLeXXhp7oUu4y/0uO6+OdYt2EwhjwJZybtw89hNLELnCL5qxXaZJDUnQAfuZZKCOA tlDr4vu5/9u/h/gv1BrcWvQAQU2utNjVDAp+Sni216O68Y84gkUaEBKkIuexR9P/psbT gfoQ==
X-Gm-Message-State: AHQUAuY5SjqVSYYP8Dp9a19RQI9XK/ET4tS+Ctdc5T5vSY6rFmqxyJy6 UBDx+Le004tFnfepZGy9FuYLu1bUMdHcNDTHSrolzep8
X-Google-Smtp-Source: AHgI3IZM/RpfgQ6z50h4yolpC/D1atzYCW/RjxNgKlhSXmiWzOvXNNkHzzpWPcQVuMneN7EtN9pOocozP4ozNGDR0BI=
X-Received: by 2002:ac8:38ba:: with SMTP id f55mr32200094qtc.192.1550772395135; Thu, 21 Feb 2019 10:06:35 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: "Andrew G. Malis" <>
Date: Thu, 21 Feb 2019 13:06:23 -0500
Message-ID: <>
To: Carlos Pignataro <>
Cc:,,, IETF Discussion <>,
Content-Type: multipart/alternative; boundary="000000000000bd572905826b55f9"
Archived-At: <>
Subject: Re: [mpls] Opsdir last call review of draft-ietf-mpls-sfc-encapsulation-02
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 21 Feb 2019 18:06:39 -0000


Many thanks for your review! I'm also including the SFC WG on my reply.

Comments inline.

On Wed, Feb 20, 2019 at 10:58 PM Carlos Pignataro <>

> Reviewer: Carlos Pignataro
> Review result: Has Issues
> Reviewer: Carlos Pignataro
> Review Result: Has Issues
> I have reviewed this document as part of the Operational directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These
> comments were written with the intent of improving the operational aspects
> of
> the IETF drafts. Comments that are not addressed in last call may be
> included
> in AD reviews during the IESG review.  Document editors and WG chairs
> should
> treat these comments just like any other last call comments.
> This document is highly readable, includes very clear textual
> descriptions, and
> is very well organized. Easy to read in its simplicity. However, it would
> benefit from a more explicit connection to the transport encap mechanics
> from
> RFC 8300 (e.g., S4, S6.1). Specifically, I'd recommend adding a Figure or
> an
> SFF NSH Mapping Table example, to depict and/or exemplify the SFF function.

I'm trying to envision what would make a good figure here. We could add an
additional line to Table 1 of RFC 8300 and reference that table:


      | SPI  | SI   | Next Hop(s)         | Transport Encapsulation |

      | 25   | 220  | Label 5467          | MPLS                    |


Is that what you had in mind? If not, I'm open to other suggestions.

> >From an Operational standpoint, the document seems largely appropriate in
> terms
> of dataplane considerations. Some key considerations are explicitly out of
> scope:
>    The method used by the downstream receiving node to advertise SFF
>    Labels to the upstream sending node is out of scope of this document.
> This really seems to mean that, with the simple definition in this
> Informational document, interoperable implementations cannot yet exist. If
> there is no mechanism to advertise the SFF Label or to manage the
> semantics of
> this particular label, how will it know? Static configuration, which is not
> covered anyway, is not in my humble opinion a manageable scalable approach.

Actually, while it is outside the scope of this document, it is within the
scope of draft-ietf-bess-nsh-bgp-control-plane, and text is being added to
the next revision of that draft to show how it can be used to signal the
encapsulation defined here. This was worked out after this draft was
forwarded to the IESG, but we can now add a reference to that draft seeing
as we'll be doing a post-last-call update.

> Title: MPLS Encapsulation For The SFC NSH
> RFC 8300 makes an explicit distinction between the terms 'encapsulation'
> and
> 'transport encapsulation' (see e.g., Figure 1, Section 1.5 5., and Section
> 4 of
> RFC 8300).
> It seems to me that this is the "MPLS Transport Encapsulation for the SFC
> NSH"

Thanks, we'll fix that.

> 2.  MPLS Encapsulation Using an SFF Label
> Similarly, "2. MPLS Transport Encapsulation Using an SFF Label"
>    The encapsulation is a standard MPLS label stack [RFC3032] with an
>    SFF Label at the bottom of the stack, followed by a NSH as defined by
>    [RFC8300] and the NSH payload.
> Insteadf of "NSH payload" I think "orignal packet" is meant.

RFC 8300 uses both "payload" and "original packet/frame", but the latter
more than the former. So we can change "payload" to "original packet/frame".

> Also, this encapsulation is Underdefined: What is the value of TTL? TC?

I've been looking back at other related RFCs (such as PW and IP VPN label
definitions) and they're also mostly silent on these values. I did find the
following in RFC 6073:

   The setting of the TTL of the PW MPLS
   label is a matter of local policy on the originating PE, but SHOULD
   be set to 255.

Regarding the TC, we can follow the example of RFC 6391:

   This document does not define a use for the Traffic Class (TC) field
   [RFC5462 <>] (formerly known as
the Experimental Use (EXP) bits
   [RFC3032 <>]) in the flow label.
Future documents may define a use for
   these bits; therefore, implementations conforming to this
   specification MUST set the TC field to zero at the ingress and MUST
   ignore them at the egress.

Do you have any alternative suggestions?

>    Much like a pseudowire label, an SFF Label is allocated by the
>    downstream receiver of the NSH from its per-platform label space.
> A PW Label is more restrictive. RFC 8077 says it MUST be allocated as
> per-platform:
>    egress LSR only.  Note that the PW label must always be at the bottom
>    of the packet's label stack, and labels MUST be allocated from the
>    per-platform label space.
> Is this the case for the SFF Label as well? If so, what is the implication
> of
> the MUST? If not, why is it different than other equivalent similar labels?

We can change the text to:

 Much like a pseudowire label, an SFF Label MUST be allocated by the
downstream receiver of the NSH from its per-platform label space, since the
meaning of the label is identical independent of which incoming interface
it is received [RFC3031].

>    2.  Push the SFF Label to identify the desired SFF in the receiving
>        MPLS node.
> TTL value? 1? 2? 255 for GTSM? GTSM RFC 5082 could be used here.

As I noted above, 255, although I used RFC 6073 as my source rather than
5082. We'll add that here as well.

> 4.  Operations, Administration, and Maintenance (OAM) Considerations
>    OAM at the SFC Layer is handled by SFC-defined mechanisms [RFC8300].
>    However, OAM may be required at the MPLS transport layer.  If so,
>    then standard MPLS-layer OAM mechanisms such as the Generic
>    Associated Channel [RFC5586] label may be used.
> RFC 5586 is _not_ an OAM mechanism. It is an associated channel creation
> mechanism, over which OAM could be carried.
> Thus, what traditional MPLS OAM can be carried here? Things like RFC 4379
> / RFC
> 8029 would need the definition of an SFF Label FEC (which does not exist).
> Which other one? IP/ICMP seems of very limited value.

That's a good point about RFC 5586. The intention is that the MPLS OAM
would be at the transport label layer above the SFF label, so most any
MPLS-layer OAM would be applicable. So how about rewording to make that
more clear:

OAM at the SFC Layer is handled by SFC-defined mechanisms [RFC8300].
However, OAM may be required at the MPLS transport layer.  If so, then
standard MPLS-layer OAM mechanisms may be used at the transport label layer
(the labels above the SFF label).

> 6.  Security Considerations
> Have you considered the use of GTSM?

No, we hadn't. Can you point me to any examples of GTSM being used in an
MPLS or PW context?

> 8.  References
>    [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
>               Chaining (SFC) Architecture", RFC 7665,
>               DOI 10.17487/RFC7665, October 2015,
>               <>.
> SHould RFC 7665 be Normative? It defines the "SFF" which is quite central
> to
> understanding this document.

Good point. It was there because 7665 is an Informational RFC, but RFC 8067
does allow normative references to informational RFCs, so I'll move it.

> Other Nits and Editorials:
>    SFF Labels are similar to other service labels at the bottom of an
>    MPLS label stack that denote the contents of the MPLS payload being
>    other than IP, such as a layer 2 pseudowire, an IP packet that is
>    routed in a VPN context with a private address, or an Ethernet
>    virtual private wire service.
> This says "being other than IP, such as IP", which seems to be
> self-contradictory :-)
> :-)

How about we change "other than IP," to "other than a normally routed IP

Thanks again,