Re: [mpls] Martin Vigoureux's Yes on draft-ietf-mpls-sfc-05: (with COMMENT)

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 11056129570; Thu, 7 Mar 2019 07:18:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fv_YT9V1K6UA; Thu, 7 Mar 2019 07:18:41 -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 D8101128664; Thu, 7 Mar 2019 07:18:40 -0800 (PST)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id x27FIbKn017035; Thu, 7 Mar 2019 15:18:38 GMT
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 9C5F622042; Thu, 7 Mar 2019 15:18:37 +0000 (GMT)
Received: from (unknown []) by (Postfix) with ESMTPS id 8665D22044; Thu, 7 Mar 2019 15:18:37 +0000 (GMT)
Received: from LAPTOPK7AS653V ([]) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id x27FIU3j008203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 Mar 2019 15:18:32 GMT
From: Adrian Farrel <>
To: 'Datatracker on behalf of Martin Vigoureux' <>, 'The IESG' <>
References: <>
In-Reply-To: <>
Date: Thu, 07 Mar 2019 15:18:28 -0000
Organization: Old Dog Consulting
Message-ID: <017701d4d4f9$086b4520$1941cf60$>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AQCrbVAqMWWaUaEgKivLtWot7l5xIqhTFCrA
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--17.223-10.0-31-10
X-imss-scan-details: No--17.223-10.0-31-10
X-TMASE-Result: 10--17.222700-10.000000
X-TMASE-MatchedRID: L8tZF6zWW2rxIbpQ8BhdbOYAh37ZsBDCLi2dwKiMR9xRXC4cX65cJCZK RIFpXA+BDv95a5ffqZv0+OmUKqID0AKVP1EUmtp5e5NWR5iixe1umrZiQVqsmQW3kEiN4kyfmtG /PWE2jkzsUepPGbNH8K0VV84ptAp6TPc9mhbHBd1+7IhLVmN+u3yzymMiw5QH1VNlojpO42g5d9 n04fLNZiWxb0EdRU2U+iHR6Lif927vXvInwhwK28K1Ib9JAALxdZPoD9V2prSbKItl61J/ybLn+ 0Vm71LcBXW7Bvonl8cLbigRnpKlKSPzRlrdFGDwlJoDb7wA2DbJ4YdyuydLW8LGYglzDlW3h6fG WY6pEO+H7Szq/aKVdw==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <>
Subject: Re: [mpls] Martin Vigoureux's Yes on draft-ietf-mpls-sfc-05: (with 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:18:43 -0000

Hi Martin,

Thanks for your thoughts.

> I know I'm being too pernickety:

As is your right 😉

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

Oh, dear. Yes, you're right about the word "forward". It crops up too often with too many meanings.

I think the tidies solution is to change the first quote to say...

   An SFF MUST decrement the TTL by one each time it performs a
   lookup to forward a packet to the next SFF.

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


mpls mailing list