Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-sfc-04.txt

"Adrian Farrel" <> Mon, 07 January 2019 21:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5C84C12D7F8; Mon, 7 Jan 2019 13:20:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aMLDLXkTnvNy; Mon, 7 Jan 2019 13:20:50 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6F0BD12D4F0; Mon, 7 Jan 2019 13:20:50 -0800 (PST)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id x07LKhLR031732; Mon, 7 Jan 2019 21:20:43 GMT
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 38D7A2203A; Mon, 7 Jan 2019 21:20:43 +0000 (GMT)
Received: from (unknown []) by (Postfix) with ESMTPS id 23ACA22032; Mon, 7 Jan 2019 21:20:43 +0000 (GMT)
Received: from LAPTOPK7AS653V ( []) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id x07LKfpa026523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 7 Jan 2019 21:20:42 GMT
From: Adrian Farrel <>
To: 'Mach Chen' <>,
References: <> <000901d4a53a$0e619770$2b24c650$> <>
In-Reply-To: <>
Date: Mon, 07 Jan 2019 21:20:41 -0000
Organization: Old Dog Consulting
Message-ID: <000f01d4a6ce$d8554e10$88ffea30$>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHy0Tq7EDt6eY0U8sxunbaewJUSUQHg0tjtAOhd3qelUa+wUA==
Content-Language: en-gb
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--27.890-10.0-31-10
X-imss-scan-details: No--27.890-10.0-31-10
X-TMASE-Result: 10--27.890400-10.000000
X-TMASE-MatchedRID: gTucSmrmRMPxIbpQ8BhdbGOho7buv7d99ISHwCrIdS+dI/DikZ1UPGn7 AlTb8W2x8P/rRROeDj5oXUhPWha39tYoPXJFOZMZSEQN/D/3cG6bKpAlY2y6SV4BFO+GiYMKrzN S6FlTLmAMSDoxTOGWgjsSJ6fCyZIk5PqteCUdhUSvPooS+PUQcvjb1e058Z7KtXl9IxEPXOqoBf Cx2HzmBpR0OVq67lyBvLG2wtZKh4AS5iXdhf8hbvHkpkyUphL9fjJOgArMOCbdeAKnvBMxfMCS2 AMm1nQC0gMnJXVXJPBN/Mei72kQGkrKMxos9ql4gQy/ei4MrjH6pOsKlhLIwgZbeEWcL03VvevW pIZtKsrqDin9jfJn1G3M9l5ohxPtL0W1btd8e54gKw/iul4Zx4ED+PNzPecB6i5zlFx/UHRJnSo 6DBNIgr+JbQH3H6GP6oRMTpXtji/Ea2ky0XHJsh47EGkpGeA9NlJkXYyJkGDxH97w0zz7daF609 GrmC7toR5IPMth3DTW8Baq43427gcSBA/LYDihXP5rFAucBUFxP3KiGWI8JxpQU1f5QXKAF0FOW tPeLaIEC1YjNkhrBnUJW3hxVXl5uZxfSEY3BwKM29hkek7XdzQAp53S718HT67yhLheQoy/HX2y oHunkk4/WT9nKDC8dQZZTOCYP9WY+dHsEP/MFZ4CIKY/Hg3AWQy9YC5qGvybk3ZgcwPRvwzKt8/ 2P4LV33fj+sMArfNRzX47Vf0DMQ==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <>
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-mpls-sfc-04.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 07 Jan 2019 21:20:53 -0000

Hmmm, I think we may disagree on this ☹

I'd ask the WG chairs and AD (especially as the review is for the benefit of the AD) to guide the authors.

IMHO it is not the place of an IETF spec to tell people how to implement unless the implementation changes the resultant behaviour on the wire. >From my perspective, this document tells the implementer what black-box behaviour is expected: i.e. what result receiving a packet should have, and what packets to generate. 

We could describe how to implement, but I can't see how that would be normative. And I think there are plenty of ways to achieve the required behaviour in an optimised way (for example, performing dual-label access). We provided section 14 to give guidance that implementation using existing hardware could be possible, but we didn't want to imply that this was *the* way to implement.


-----Original Message-----
From: Mach Chen <> 
Sent: 07 January 2019 03:52
Subject: RE: RtgDir review: draft-ietf-mpls-sfc-04.txt

Hi Adrian,

Thanks for your reply!

See some response inline...

> -----Original Message-----
> From: Adrian Farrel []
> Sent: Sunday, January 06, 2019 5:03 AM
> To: Mach Chen <>;
> Cc:;;
> Subject: RE: RtgDir review: draft-ietf-mpls-sfc-04.txt
> Hi Mach,
> Thanks for your careful review.
> > Minor Issues:
> > *	Section 13 says:
> > "
> >   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.
> >
> >   c.  SFa performs its designated function and returns the packet to
> >       SFFa.
> >
> >   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 sends
> >       the packet with two label stack entries:
> >"
> > From above text, it seems that an SFF will have different process for
> >a
> packet that
> > has the same SPI/SI.
> >  1) if a packet is received from a previous SFF, it will match the
> > SPI/SI
> and determine
> >  to where the packet will be sent.
> >  2) if a packet is received from an SF, it will directly modify the
> > inner
> label, and then
> > by matching the new SPI/SI to determine to where the packet will be sent.
> >
> > Is this the intention ? If so, how does an SFF determine whether a
> > packet
> is from an
> > SFF or from SF?
> You have understood the processing correctly.
> In fact, the same situation exists with NSH processing: the SFF is expected to
> "know" whether the packet has arrived from the previous SFF or from the SF.
> There are probably two answers:
> Firstly, it is entirely possible that the SFF and SF are co-resident. That is, they
> form part of the same implementation, possibly being separated by an API.
> In this case, of course, the question does not arise.
> Secondly, it is reasonable to expect that the SFs are attached to the SFF by
> dedicated tunnels or ports (indeed, SFs are port-attached in the legacy
> service function world) so that a packet arriving on a line interface (from
> another SFF) is easily distinguished from one that arrives from an SF. (You
> might think about port-attached L3VPNs to help clarity how this could work).

If so, it's better to add some text to clarify this. Given the current text, it implies that it could be determined just by matching the SPI/SI.

> > In addition, how does an SFF apply the swap and/or pop operations here.
> E.g., when an SFF looks up the SPI,
> > it matches an item in a local table; what operation (swap or pop) will
> apply to the SPI label? According to " The
> > packet is forwarded to SFa unmodified." It seems implies that there is
> > no
> any operation will be applied. If so,
> > this will not align with the MPLS.
> I think you should also look at this in the manner of a L3VPN. That is, the top
> label is popped to derive the context, the forwarding label is looked up
> within the context and swapped, and the context label is re-imposed as the
> packet is forwarded.
> Of course, there are optimisations on how an SFF might implement this, but
> we don't need to describe those. What we know is that the VPN-like
> approach can be made to work with existing PEs.

As above, it's better to add some text to make it clearer. 

> > If the above issues exist, the " context/SF" case has the similar issues.
> Hope I have explained why this is not an issue.
> Now, we could debate why we have not made these answers more clear in
> the text.
> The first thing is that we are not trying to make any changes to the
> architecture used for NSH, so we did not feel we should go into explanations
> about how the SF/SFF relationship works.
> Additionally, we did not feel that (beyond the short section 14) we should tell
> people how to implement. The purpose of the document is to describe wire
> formats.

IMHO, it may not be enough if just describing the wire formats, the operations/process on the "formats" are necessary to make it an implementable and interoperable protocol. 

Although Section 13 is listed as a worked example, I personally think that they are necessary procedures. I'd suggest to change it to more "formal" section, e.g., Procedures. 

Best regards,

> Best,
> Adrian