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

"Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <martin.vigoureux@nokia.com> Fri, 08 March 2019 12:38 UTC

Return-Path: <martin.vigoureux@nokia.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD6212797D; Fri, 8 Mar 2019 04:38:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYnye1TVoad4; Fri, 8 Mar 2019 04:38:20 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150129.outbound.protection.outlook.com [40.107.15.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7971F1276D0; Fri, 8 Mar 2019 04:38:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BzaRdQJ+G+3HqTUi7EaeMsQDHS5qnfB69bMu7VVkp7o=; b=cHGNVzH3Wq45tde/+fn0HS795brWu4gJfc7BnBxgsziw43Bkve7Awajr8Lx1Y83dVvQ6cHKzEYegrxofPtWUQWQQXrcSIcO4FswlCmY2lqKELXNnneYhn2uIvQSVQM8FffH+1+/jrc9HeLqf8KwPdWCHuDbBHIs56F4obgpC0cQ=
Received: from VI1PR07MB6142.eurprd07.prod.outlook.com (20.178.124.157) by VI1PR07MB5919.eurprd07.prod.outlook.com (20.178.81.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.8; Fri, 8 Mar 2019 12:38:17 +0000
Received: from VI1PR07MB6142.eurprd07.prod.outlook.com ([fe80::5d24:f062:104a:b2f2]) by VI1PR07MB6142.eurprd07.prod.outlook.com ([fe80::5d24:f062:104a:b2f2%4]) with mapi id 15.20.1709.009; Fri, 8 Mar 2019 12:38:17 +0000
From: "Vigoureux, Martin (Nokia - FR/Paris-Saclay)" <martin.vigoureux@nokia.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, 'Datatracker on behalf of Martin Vigoureux' <ietf-secretariat-reply@ietf.org>, 'The IESG' <iesg@ietf.org>
CC: "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "draft-ietf-mpls-sfc@ietf.org" <draft-ietf-mpls-sfc@ietf.org>
Thread-Topic: [mpls] Martin Vigoureux's Yes on draft-ietf-mpls-sfc-05: (with COMMENT)
Thread-Index: AQHU1avOKQVAkk7q+EK9h1C8IIJl2Q==
Date: Fri, 8 Mar 2019 12:38:17 +0000
Message-ID: <9ae094f5-3618-b14a-cb0f-e965ab7e2b9e@nokia.com>
References: <155186757563.24618.8284642177706375034.idtracker@ietfa.amsl.com> <017701d4d4f9$086b4520$1941cf60$@olddog.co.uk>
In-Reply-To: <017701d4d4f9$086b4520$1941cf60$@olddog.co.uk>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [131.228.2.20]
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
x-clientproxiedby: MR2P264CA0016.FRAP264.PROD.OUTLOOK.COM (2603:10a6:500:1::28) To VI1PR07MB6142.eurprd07.prod.outlook.com (2603:10a6:803:da::29)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b71b952c-cd24-466f-fe66-08d6a3c2f05c
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:VI1PR07MB5919;
x-ms-traffictypediagnostic: VI1PR07MB5919:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <VI1PR07MB5919F7D454A7B0D6A39F9CE88C4D0@VI1PR07MB5919.eurprd07.prod.outlook.com>
x-forefront-prvs: 0970508454
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(346002)(39860400002)(366004)(136003)(54094003)(189003)(199004)(6486002)(6116002)(6246003)(3846002)(2501003)(64126003)(229853002)(97736004)(6436002)(86362001)(36756003)(52116002)(486006)(11346002)(305945005)(476003)(7736002)(31696002)(99286004)(2616005)(446003)(71190400001)(5660300002)(26005)(14454004)(186003)(71200400001)(256004)(6346003)(966005)(105586002)(8936002)(106356001)(8676002)(31686004)(386003)(110136005)(316002)(4326008)(58126008)(6506007)(65806001)(65956001)(76176011)(478600001)(6306002)(54906003)(6512007)(66066001)(65826007)(81156014)(81166006)(25786009)(102836004)(68736007)(53936002)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB5919; H:VI1PR07MB6142.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=martin.vigoureux@nokia.com;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: K7acefo4O5fkXMl6zLTFpxEbwoQzONbpQ73iSFxsLVTgPke1cyWtJzO+yBgSRCWp1wEHb4jJz00ZpG0IWW1ttdfBU+0ptY/ovXBoKQpZeGDp6FiHUe3nBoMI20Y8UotpWDDLywtRHhxWcVxxBRfOSLj9GURMeOaYhBaKKY4mJzz/g0cSQnzkTLLT7AKOpIsD3d60P//Hr6nVIti5NgF3zWAMiFzC3OL59rORHxpul741Js3jtMoS/2bE70IBcerat+Co03a68Tg6gmBfapp8ovNUcwrVYAyyXuBVu7mbjCUEcjpCCfcnFDVv52tGXrbE5X03C96Z5NEF1gE9jUkmZ6WxiwcDd6tF2zu/AxrOmQQ9ECusNJgKjt4jHL4cLYff9/0vQqtYOI8qOjXRijalUMRhhb5eQKNaLgA6DEEXp68=
Content-Type: text/plain; charset="utf-8"
Content-ID: <EE0C5935E9C05A4A9D6E858389A70BF1@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b71b952c-cd24-466f-fe66-08d6a3c2f05c
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2019 12:38:17.3774 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5919
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/_TGkK-Dy_ntNuFleozyY-fPLvxw>
Subject: Re: [mpls] Martin Vigoureux's Yes on draft-ietf-mpls-sfc-05: (with COMMENT)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Mar 2019 12:38:23 -0000

Thanks Adrian, that's perfect.

Le 2019-03-07 à 16:18, Adrian Farrel a écrit :
> Hi Martin,
> 
> Thanks for your thoughts.
> 
>> COMMENT:
>>
>> 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 ?
> 
> Yup
> 
>> s/document)./document./
> 
> Ack
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
> 
>