Re: [mpls] Eric Rescorla's Discuss on draft-ietf-mpls-sfc-05: (with DISCUSS and COMMENT)

"Adrian Farrel" <> Thu, 07 March 2019 15:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BE81D1313F5; Thu, 7 Mar 2019 07:42:25 -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 PuJYUfzEs-an; Thu, 7 Mar 2019 07:42:24 -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 D1AC11313DE; Thu, 7 Mar 2019 07:42:23 -0800 (PST)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id x27FgJUB016107; Thu, 7 Mar 2019 15:42:21 GMT
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 89BD32203A; Thu, 7 Mar 2019 15:42:21 +0000 (GMT)
Received: from (unknown []) by (Postfix) with ESMTPS id 7E57322042; Thu, 7 Mar 2019 15:42:21 +0000 (GMT)
Received: from LAPTOPK7AS653V ([]) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id x27FgBfe014751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 Mar 2019 15:42:15 GMT
From: Adrian Farrel <>
To: 'The IESG' <>
References: <>
In-Reply-To: <>
Date: Thu, 07 Mar 2019 15:42:07 -0000
Organization: Old Dog Consulting
Message-ID: <018401d4d4fc$581475d0$083d6170$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQHuEEooEDNys56SgSz6gC1u6beC7qXN1SMQ
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--14.754-10.0-31-10
X-imss-scan-details: No--14.754-10.0-31-10
X-TMASE-Result: 10--14.754400-10.000000
X-TMASE-MatchedRID: y/2oPz6gbvjxIbpQ8BhdbOYAh37ZsBDC0i/hFXziUdM0QmmUihPzrIuy XZ8/ROb4Gp8kmQmE0VAH75OaJJ1WU3ZFqfLxlafeCDuvg040bNwrHkgIan9a0fgnJH5vm2+gxGS h4nc4VFyhiTUrlW9Gg4BH6yFwyE6p6AmTKL8Tl2/4vYawCsCC2hNzcbBs7azLWabPstVV86mlGs yRp40hY8yVrKX5W8M1lFieF0i0o5p/JtSSO8GR9QdOQdS09jPF8lW420oy1gwwplGJ7NxS0/m0Y T+bdWquT5dYubiiJHl7/ppjELPtsk1+zyfzlN7y/sToY2qzpx7af1N18C+ZArDszp3K5gqDjocz muoPCq2iQTRSLBMLOHcGNO2USSo0UcsFmibe+Xx4LqXwj4w/q2dpB61dVpJP
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <>
Subject: Re: [mpls] Eric Rescorla's Discuss on draft-ietf-mpls-sfc-05: (with DISCUSS and COMMENT)
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, 07 Mar 2019 15:42:26 -0000

Thanks Ekr, that is an exceptionally good catch.

It is both a simple problem and a real problem.

A fix is going to take some thought and at least a few words.

At a quick glance, I think the issue would at least get caught when an
attempt to use the metadata was made (the index would not find an entry).
That would cause an error to be flagged.

But there are "update" cases that would not work.


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

Yes. Easy addition to Section 15