Re: [mpls] A question about draft-ietf-mpls-sfl-framework

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Thu, 03 January 2019 16:31 UTC

Return-Path: <Alexander.Vainshtein@ecitele.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 87F12131134; Thu, 3 Jan 2019 08:31:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.69
X-Spam-Level:
X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.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 PFLeFHPCvcYs; Thu, 3 Jan 2019 08:31:40 -0800 (PST)
Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.2]) (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 E4F53130EC6; Thu, 3 Jan 2019 08:31:39 -0800 (PST)
Received: from [85.158.142.101] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-2.bemta.az-a.eu-central-1.aws.symcld.net id F6/5D-14999-9E83E2C5; Thu, 03 Jan 2019 16:31:37 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA1WSbUhUWRjHPffcuXMVbxxHzUe3lm3yQ7TeySl JYzXnS0uwGywIRa1SV705A+PV5o6pEVFBa5a990FnZzFFDd9mxSTLFg17VQshqMyyF3XKLIKy FzSt7p2jbX25/M7z//+f5zmXw2OTn4vh5SK37FIkp5kLYRMW2TLEsSRLenzHk4SkSxNLkgZr6 w1JvY8lG1573jNkXFtTM8n8wWwyOJTMvKItBntZpxfl942iot4L+4y7UcMNdAAF8yypxnCyPf EACuFN5DAD3X17WHp4gGCyq5TTXRxJgdbGoQBHEBGapl5wugmTTgQ9pSe0A8+Hk1+gqaOQepL BV+vBlH+Fyxf/NegWlsRC2xGbXhZIBvzt8SM66wQDV6ePBPzB2qyXpycZnRGZDx96mwKMSRQM jlYGGAiBmv/6MeVIeD7yyUD9mfDIX4VofRGUP/QaKS+EW5UHA8OA3OXgykzPbNgK1+q7Znkdt J97ifRFgSyGtrEMWh5EUDGVRnkpHNzXPtvfCSWH2jHteR9DZetDI80ugKHO9bR+hoP+k8OB5U wkC657J1ga/hEaDj1hj6I4zzd382hxTBTo+PiDJ/CPwqCnYpSlljg4deENR/lnqKt6gef4xsU R5tv6KWRsQKsyXY4cuztXcjhFa3y8aLWuEJeL1sSVFmmHKFnkAjFLVtwuSVMtUqFqUYtzs5zZ FkV2tyLtgWVvY1rOoadVOd0ommfMkULCgJhumpeZl11sl1T7ZleBU1a70QKeN4PQuNKSbgpzy Tly0VaHU3ulczLwoeYIwa/Lgpov5aqOHCr1olR+uHx/OeZfBb77fXVezF8rfefFJlbJU+SYKG FNohYjesxeoHxtOvf6b6GFMeECCgoKMoXmy65ch/t7fRxF8cgcLoToXUIdivvr7HFtLUZbKwH i9LXc0v9SzG4UUfkRVd9pXn38/K7769Kq40ZqS1JnpmK7zvp89mnOtLF4/rN/hD9Hjt9swxs8 e6f3ODfaljVILWUlO1dt6mmOnqnNSDHMs23pK/T3vw+VI8tSw5TP7uCJ6OY3UeGvse+n7eq75 J1/XZUHiisKlt/OS0l+O9A1ec/x+9jYpdb634KPmVnVLlmXYpcqfQEU9nQv+AMAAA==
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-38.tower-226.messagelabs.com!1546533092!3808936!1
X-Originating-IP: [52.33.64.93]
X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass
X-StarScan-Received:
X-StarScan-Version: 9.14.24; banners=ecitele.com,-,-
X-VirusChecked: Checked
Received: (qmail 23655 invoked from network); 3 Jan 2019 16:31:35 -0000
Received: from us-west-2b.mta.dlp.protect.symantec.com (HELO EUR04-HE1-obe.outbound.protection.outlook.com) (52.33.64.93) by server-38.tower-226.messagelabs.com with AES256-SHA256 encrypted SMTP; 3 Jan 2019 16:31:35 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tS+ST/HNYmgIjVBvlngkbfh6f9UxVjT4oKk7qUKe4V0=; b=Jj14uKYYsJP2iSdzSwi8qHmbwachvaafhYLdw/UG641wKCUn4wATRbhdFTxk7Cs4ofQp2WkZDTIpr3oBUxVwb+quB5q8J6tOY/V7Rtd72sY+G4dLsqPViKitVJ3pQEwRO1Q51aw8YlvUojcz/zQWvRaHvAzOVhpvgjXz9F3x2sc=
Received: from VI1PR03MB3839.eurprd03.prod.outlook.com (20.177.54.23) by VI1PR03MB3151.eurprd03.prod.outlook.com (10.165.191.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1471.20; Thu, 3 Jan 2019 16:31:29 +0000
Received: from VI1PR03MB3839.eurprd03.prod.outlook.com ([fe80::39ab:94a:ab19:b503]) by VI1PR03MB3839.eurprd03.prod.outlook.com ([fe80::39ab:94a:ab19:b503%5]) with mapi id 15.20.1495.005; Thu, 3 Jan 2019 16:31:29 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: Stewart Bryant <stewart.bryant@gmail.com>
CC: "mpls@ietf.org" <mpls@ietf.org>, Shell Nakash <Shell.Nakash@ecitele.com>, Jun Ye <Jun.Ye@ecitele.com>, "draft-ietf-mpls-sfl-framework@ietf.org" <draft-ietf-mpls-sfl-framework@ietf.org>
Thread-Topic: A question about draft-ietf-mpls-sfl-framework
Thread-Index: AdScRaSNUIIl9sN8QmyDA//QSoo/eQHKsTQAAAEt8PAAAphBAAAARMpA
Date: Thu, 3 Jan 2019 16:31:29 +0000
Message-ID: <VI1PR03MB38394B752504E5D2D0365C059D8D0@VI1PR03MB3839.eurprd03.prod.outlook.com>
References: <AM0PR03MB3828DD11E7BCB069CB2B68DA9DB40@AM0PR03MB3828.eurprd03.prod.outlook.com> <36264762-7e7a-bd18-da0c-4db51185d426@gmail.com> <VI1PR03MB383925F57BF94AFF0A4A155F9D8D0@VI1PR03MB3839.eurprd03.prod.outlook.com> <0d5334e3-a2f9-ba99-1cbe-2602c26dbe92@gmail.com>
In-Reply-To: <0d5334e3-a2f9-ba99-1cbe-2602c26dbe92@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.234.241.1]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR03MB3151; 6:lBMa4lr9YWPGom/EybA3usTl8HAjhn9PL6et1wIAIJN9DtQgEu98cApZd5epBvFZGdV8lRByTNNTZZ2LHAc/ZuKy3BQcILsBbBKbavJPxWi8QmSFEPjHihKmUlhYpHAxT0dPsJUnWR8HytRm2NYld96trkDP260c1CfKFvIpjdb/+a0w3DAOZYR5t+rgdDs+TrXuOmVHTuHGs7jej5tOiH3tjD6zEQzRq+80zhR7kygZGH3/rAGfAx0n44wIEY/3oAIVvEIB6wjHojB9Rctc1CfexkHodXsUPfjm7EbXLKqLambQjV5So9kSdoinjGJGyI86Romuivze3nEpsWToPL/wT8tr1zRCDuh2+VLtqEiMlsDne0xDdvzva+3No6NMAyjfIYQKCeKD8bag2fep5wXwUpmNCuo27amBLLdsux/lKnFPA3JTustwNq7g5ikbKohS6pCAVPSi9HOeCLBjUg==; 5:5N0ZT6f3L5BQ2f9XAiRpUUFl2dVRwDW7nRVq47cWkLKo8Qnq8sWaWC7y54ZfdnZdTxTd3Kx2wldY3z/Wqx82hCxOynhCtYMEcuon3KqNkQWaC4ito2yP6KUvYmFszBe+7hze9YWzezOa5FbSJIc4kCcMaMocqbIiEPA8ee8UDk4=; 7:qs9xysdbk1DM/oizhIVJwGg5pOHljxCTT7PVUbDXHEdk7yLYsNC2BysFtboNn8ExYWjU4yBGrxmlL3d4n6vSIUC5LghxYpSd9L3JJImM0bzaNLa0RvQhBffb7kZoiZfhrHB5chOM2y98jG2WrQ4gRw==
x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR;
x-ms-office365-filtering-correlation-id: d55e915b-8e0a-49a2-6635-08d67198ea36
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR03MB3151;
x-ms-traffictypediagnostic: VI1PR03MB3151:
x-microsoft-antispam-prvs: <VI1PR03MB31510DBF1163A743F722895B9D8D0@VI1PR03MB3151.eurprd03.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(908002)(999002)(5005026)(6040522)(8220060)(2401047)(8121501046)(3231475)(944501520)(52105112)(10201501046)(3002001)(93006095)(93001095)(6055026)(6041310)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:VI1PR03MB3151; BCL:0; PCL:0; RULEID:; SRVR:VI1PR03MB3151;
x-forefront-prvs: 0906E83A25
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(136003)(39860400002)(396003)(376002)(189003)(199004)(51874003)(54094003)(76176011)(7696005)(236005)(9686003)(53546011)(55016002)(446003)(6306002)(54896002)(6506007)(93886005)(54906003)(102836004)(316002)(25786009)(97736004)(4326008)(186003)(606006)(6916009)(6246003)(6436002)(26005)(478600001)(53936002)(229853002)(11346002)(39060400002)(86362001)(561944003)(33656002)(99286004)(14444005)(256004)(14454004)(476003)(68736007)(106356001)(66066001)(5660300001)(105586002)(790700001)(71200400001)(71190400001)(72206003)(81156014)(8936002)(8676002)(74316002)(7736002)(6116002)(3846002)(81166006)(486006)(2906002)(966005); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR03MB3151; H:VI1PR03MB3839.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: OGAHELvt9q3rCOBBK5FH5z5DNikbq7wxeqd74bd039Y0h7qTsH1tki3hkJzF/G5hytMSj3O6DqATo+KX3GESwK3QnUVwLVko7zWMdl1YEWGUdNbI4IfPZIqCjFUqTjGTGO0p7bv8tFcmDl48v9AoPwNb20bnKNK1sSnMF1DsJNCOdFhk9FSuELSq7v5a2CfJKCu6rJf1Cn6Fw26qrcnir6A6SEAiwh/u4y6QnxCEOzM1dusKxG+WJbQQ52yq6+qqgIDNHwqtHgOUsvkoZlFgHNgL2pCTho2jaqsuTdSO6U1zPPBA8m71JvK6CZu9gfyz
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_VI1PR03MB38394B752504E5D2D0365C059D8D0VI1PR03MB3839eurp_"
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d55e915b-8e0a-49a2-6635-08d67198ea36
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2019 16:31:29.6704 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB3151
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/DDQwQiwlFZ47cHkk9Zw0QJ2Oq_Y>
Subject: Re: [mpls] A question about draft-ietf-mpls-sfl-framework
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: Thu, 03 Jan 2019 16:31:43 -0000

Stewart,
Lots of thanks for a prompt response.

Please note that in inter-AS Option B (and Option A) there are no PE-to-PE tunnel LSPs between PEs in different AS (obvious in Option A where the link between AS simply does not support MPLS).

I see two possibilities for IP VPNs

1.       The address TLV carries the (globally) routable  address of the Querier PE. In this case you can send the Reply using some form of an IP tunnel, e.g., MPLS-in-GRE. Security issues can be non-trivial

2.       The address TLV carries some stable IP address in the "Querier VRF" that is reachable from the Responding VRF (i.e. the responding VRF has a labeled IP route with this address as its destination prefix. In this case you can send the Reply using GAL and GACH under the application label for this address.
The first of these options would work also for EVPN, the 2nd will not (or so I think).

Does this make any sense to you?

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@ecitele.com

From: Stewart Bryant <stewart.bryant@gmail.com>;
Sent: Thursday, January 3, 2019 6:15 PM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>;
Cc: mpls@ietf.org; Shell Nakash <Shell.Nakash@ecitele.com>;; Jun Ye <Jun.Ye@ecitele.com>;; draft-ietf-mpls-sfl-framework@ietf.org
Subject: Re: A question about draft-ietf-mpls-sfl-framework


Sasha,
On 03/01/2019 15:19, Alexander Vainshtein wrote:
Stewart,
Lots of thanks for a very detailed response.

I have completely missed the (now expired) SFL Control draft. It looks to me as a reasonable approach for applying SFL to PWs (and PW-based services) and LSPs.
But using it with BGP-based services, be it BGP/MPLS IP VPN or EVPN (including EVPN-based VPWS services) would be non-trivial IMHO:

-          There are no (bi-directional) PWs in these services
No, but to do a performance measurement we need to establish a label that is unique to the pair.


-          There may be no end-to-end tunnel LSPs (e.g., if inter-AS Option B is used)

If it is interAS there may be a security issue, but Section 4 specifies the use of the RFC6374 return address TLV so we can get the message to the responder on the normal LSP and get the reply back using IP.



-          Sending SFL Request messages with GAL and ACH following the VPN application label is possible, but I do not see how the Reply can be sent back

-          I do not think these messages can be piggy-backed on MP-BGP (even if these days lots of things are).
Did I miss something?

Please look at section 4. The only concern I have is whether I need to add security to the system to cope with the inter AS case.

Best regards

Stewart



Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>

From: Stewart Bryant <stewart.bryant@gmail.com><mailto:stewart.bryant@gmail.com>
Sent: Thursday, January 3, 2019 4:27 PM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com><mailto:Alexander.Vainshtein@ecitele.com>; draft-ietf-mpls-sfl-framework@ietf.org<mailto:draft-ietf-mpls-sfl-framework@ietf.org>
Cc: mpls@ietf.org<mailto:mpls@ietf.org>; Shell Nakash <Shell.Nakash@ecitele.com><mailto:Shell.Nakash@ecitele.com>; Jun Ye <Jun.Ye@ecitele.com><mailto:Jun.Ye@ecitele.com>
Subject: Re: A question about draft-ietf-mpls-sfl-framework



On 25/12/2018 11:45, Alexander Vainshtein wrote:
Dear authors of draft-ietf-mpls-sfl-framework<https://tools.ietf.org/html/draft-ietf-mpls-sfl-framework-04>;,
I have a question about use of Synonymous Flow Labels in the when application labels are present.
The relevant text in Section 4.1 of the draft says:

   At the egress LSR the LSP label is popped (if present).  Then the SFL
   is processed in exactly the same way as the corresponding application
   label would have been processed.

If the application label has been statically configured in the egress LSR,  then, presumably, so would be each of the Synonymous labels.
Yes.


However, if the application label has been dynamically allocated by the egress LSR and advertised to ingress LSR using some control plane mechanisms, then the synonymous labels would also have to be dynamically allocated and advertised by the same control plane mechanisms.

Not necessarily.

We had a proposal for a simple control plane that I propose to refresh:

https://tools.ietf.org/html/draft-bryant-mpls-sfl-control-02

The idea with this is that the application control protocol runs as normal and this protocol modifies the label for SFL purposes.

There was a lot of interest in the WG at the time for modifying each and every control protocol, but there is not much interest in writing the drafts needed to do it.

The draft in question is a framework draft and does not discuss any control plane issues (at least I have not found any mention of such issues in the text).
I wonder if any work on control plane mechanisms for advertisement of synonymous labels is going on or planned. ( A quick search in the documents of the MPLS, BESS and PALS WGs did not find any relevant documents).

Only the one I cite above.

I would be more than willing to work with anyone (actively or just as a reviewer) that wanted to write the control plane drafts.

If the intended applicability of the SFL framework is just for statically configured application labels, this should be explicitly stated in the draft IMHO.

No, I think the intent was always that there would be a control plane if needed.

Best regards

Stewart



Your timely feedback would be highly appreciated.

Regards, and lots of thanks in advance,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________