Re: [bess] draft-ietf-bess-nsh-bgp-control-plane

"Adrian Farrel" <adrian@olddog.co.uk> Sun, 01 July 2018 12:11 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92362130E79; Sun, 1 Jul 2018 05:11:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSBIlZXa4ppt; Sun, 1 Jul 2018 05:11:46 -0700 (PDT)
Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (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 2CBBF130E70; Sun, 1 Jul 2018 05:11:46 -0700 (PDT)
Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id w61CBhh4029156; Sun, 1 Jul 2018 13:11:43 +0100
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0295622040; Sun, 1 Jul 2018 13:11:43 +0100 (BST)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs1.iomartmail.com (Postfix) with ESMTPS id DD8362203C; Sun, 1 Jul 2018 13:11:42 +0100 (BST)
Received: from 950129200 ([88.128.81.183]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id w61CBeLB015968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Jul 2018 13:11:42 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: wim.henderickx@nokia.com
Cc: draft-ietf-bess-nsh-bgp-control-plane@ietf.org, bess@ietf.org, mpls@ietf.org
References: <CCDE5306-C0B3-4E6F-A1C6-895608481FC9@contoso.com> <befd7d8f838e47c685df5c37f9d1d4d5@CY1PR0501MB1274.namprd05.prod.outlook.com>
In-Reply-To: <befd7d8f838e47c685df5c37f9d1d4d5@CY1PR0501MB1274.namprd05.prod.outlook.com>
Date: Sun, 01 Jul 2018 13:11:38 +0100
Message-ID: <03ee01d41134$ab4c4160$01e4c420$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQH4tHHDxToYPTierhT1D69C8xC3QgIq+I4PpB+mKUA=
Content-Language: en-gb
X-Originating-IP: 88.128.81.183
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-23940.005
X-TM-AS-Result: No--7.032-10.0-31-10
X-imss-scan-details: No--7.032-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-23940.005
X-TMASE-Result: 10--7.032000-10.000000
X-TMASE-MatchedRID: nVQUmLJJeyZxWR+9hcFWAxLuW4a3q2WGVBDQSDMig9GqvcIF1TcLYCZQ 9n2PDQiYROwS2FMrZ3Bl8MTYZBIgt3YfM1vcFxzebCMnhMV5TW7AuWcdTSiQDaFSh25xC7Tpq8M 1tdFZKo/+jTbLDia/9OMN9fknCeVIQDSWm8bJmzKeAiCmPx4NwLTrdaH1ZWqCdcD5PxhxmQPefx 4FmMaZTOTCMddcL/gjOwBXM346/+xW2TxypOA9tBWXqrA89fZ2GCeNplCdv+y/JnXXGBF9OC6Ey LuQy3XN
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/mMZlR_VXviYsjq6wVTJ_Rm9OaJM>
Subject: Re: [bess] draft-ietf-bess-nsh-bgp-control-plane
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Jul 2018 12:11:50 -0000

Wim asked...
> would you consider adding an MPLS label to the SFIR route in order to
> support https://tools.ietf.org/html/draft-malis-mpls-sfc-encapsulation-01.

I think that the idea of making such an addition is fine, but (and no offence
meant to the authors of draft-malis-mpls-sfc-encapsulation) we might want to get
a little more stability and (of course) clarify the relationship with
draft-ietf-mpls-sfc.

It would also be worth checking whether the mechanisms included in sections
3.2.1.5 and 3.2.1.6 already do the job, whether 7.6 helps explain, and whether
the (already defined) Tunnel Encapsulation attribute can help.

Shall we spend some face time in Montreal clarifying what needs to be added?

Cheers,
Adrian