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

"Adrian Farrel" <> Sat, 05 January 2019 21:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 19BA8130E8A; Sat, 5 Jan 2019 13:03:17 -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 MwD12djflegt; Sat, 5 Jan 2019 13:03:14 -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 6E55E130E84; Sat, 5 Jan 2019 13:03:11 -0800 (PST)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id x05L34qQ016508; Sat, 5 Jan 2019 21:03:04 GMT
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 241342207C; Sat, 5 Jan 2019 21:03:04 +0000 (GMT)
Received: from (unknown []) by (Postfix) with ESMTPS id 0E30322079; Sat, 5 Jan 2019 21:03:04 +0000 (GMT)
Received: from LAPTOPK7AS653V ( []) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id x05L3227029030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 5 Jan 2019 21:03:03 GMT
From: Adrian Farrel <>
To: 'Mach Chen' <>,
References: <>
In-Reply-To: <>
Date: Sat, 05 Jan 2019 21:03:05 -0000
Organization: Old Dog Consulting
Message-ID: <000901d4a53a$0e619770$2b24c650$>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHy0Tq7EDt6eY0U8sxunbaewJUSUaVkfHSQ
Content-Language: en-gb
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--13.324-10.0-31-10
X-imss-scan-details: No--13.324-10.0-31-10
X-TMASE-Result: 10--13.323800-10.000000
X-TMASE-MatchedRID: 9d2LtCNB3NLxIbpQ8BhdbOYAh37ZsBDCLi2dwKiMR9yqvcIF1TcLYIyA j9lUwfNqFp1/6tEDSIB3Rx3OjfsQ61toL3mbtsuEg2gX/Emjy1QU/rbDiDYaoxFT6ltzclWN8kg eyY1buLPGZf0zVzr3FvjuIjwzZodcfBycIaY2IkK4jAucHcCqnYLLh2/Jcc7eRUZL9AeG8IKb0d QWUPwyjwDyXsI6/Vm2Q1qMY4/9NYP3eeQEPm9K38xmTzofEWOOKVrLOZD1BXR0QbvL4PujkA6Tn 9wDc5HX01KWVwjBeonoqy8cAWqwRRZth7gGVYH2utvHF25zoU9BrawMcuRDTuOxOq7LQlGL9vES pIDSbfTPfw8FHXPzucOCYMezD5kx9K2bK6f9yYYYBkxPlIuYCZ20dShmm+V5u/jTz8Y/keoJXkY bHAT1XHN182ai05OsQ98FZJ3pl5CF1SyzhV53s/SZ/2axrnPBfS0Ip2eEHny+qryzYw2E8M8943 oc3p3sBXW7Bvonl8cLbigRnpKlKSPzRlrdFGDwwZNo3FXhJEYT0EbhLDAiAxKPQrWPoJDHRoiM+ EEKNbDcilLKw9Et1g==
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: Sat, 05 Jan 2019 21:03:17 -0000

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

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).

> 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.

> 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
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.