Re: [mpls] Questions and comments on draft-hu-spring-sr-tp-use-case-01

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Mon, 12 March 2018 13:21 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 8EF91127369; Mon, 12 Mar 2018 06:21:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.791
X-Spam-Level:
X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_DKIM_INVALID=0.01] 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 LLRIgBRr1E_u; Mon, 12 Mar 2018 06:21:32 -0700 (PDT)
Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.142]) (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 7E042124B0A; Mon, 12 Mar 2018 06:21:31 -0700 (PDT)
Received: from [85.158.139.163] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-6.bemta-5.messagelabs.com id 0C/A8-12610-9DE76AA5; Mon, 12 Mar 2018 13:21:29 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA1VSfUyMcRy/3/M8d/dEZ4+r3FdzG+c1VGeYGzN vm+V1bMy0kufydPfY3ZV77hIbQq4V5pq8RU5cbUobZYoRFSuFyP3RGqIXIlMpxAl3zy9v//z2 +X1evr/v97cvTSpbZKE0l2LjrBbWpJENo2aNWxgb3rS7IFp74aBO96O5R677fLxDqmvOvyjV1 Tz2ooVU1PWc5/Iot/srsYaIlvIWfWLKZqkxv6GKSvIUo5QKT3IqKjuJMtEwmmIcJGS5veJFyR wl4HB1OokvLxDsbblNZKIAWsbMh5Ki5zI/DmYmQ8a1GrnfRDJeAk731otCEBMF/TXf5di0DIp 7jiGM58Lt7nKRp5iJ4O14SPqxgomBE3dKKPxaHoKsi9VioQBmLbRerhDDiBkFX+ouiV2QjAqa 210iBoYB980GEuMQeNv2Q4r9emjpyPNlaR8/FvqObMMWNTS6DopjAlNKwN36AYSFmZDpvCnF/ vFwtTMW06ugJG1Qiv0eBPnVzTIshEG66wGFMQ+n67xDOAaKvB8IHDhHwr7Ce0OBMfCpqJbEwl kZ5D59JE6gZOKh9kwf5UTTc/4ZDmMLtF2rI3PEXxoJ90+1U5jXQvcjF4nxNCjI6xrCkXCl/yH 6lz+H5IVoisBZkzlr+ExthN7KG4w2M8ubwmdoZ0eYOUFgDZyJ1QsR8YnmEuRbrT0SCSpHzsLV VWg0TWhCFPHDC6KVI/SJW3YYWcEYZ7WbOKEKjaFpDSjKdvm0kVbOwKUk8Cbffv6WgQ7UBCti/ bJCSGLNAm/AUh1aQKdWvHSQ9NXWt77zjng2dXY5SCVlSbRwoSrFV3+M8ceMdsufor/3vhGpQ4 MUSCKRKAOTOKuZt/2vv0MqGmmCFLn+KoG8xfbn7Xe+tghfW55at78tG/tXCk1Fmhr1l7UHnp1 fMSVjnXOpY7mrfp6jNTUyjL882DQnKr1l66unIRkb7W+M6+2BWYParu2FBnVQ+PH+Q4PZ+0sX ndHEeVW3eu0blpg7qNc7i1Ux69sG0uTlL03dld9urPvoGaicVOrctPu9Kkf9pKx/ZWT2JceI3 M0Vrk/ZCWmTFk/4WaChBCM7YyppFdhfGr788PIDAAA=
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-10.tower-188.messagelabs.com!1520860884!121119499!1
X-Originating-IP: [52.33.64.93]
X-StarScan-Received:
X-StarScan-Version: 9.4.45; banners=ecitele.com,-,-
X-VirusChecked: Checked
Received: (qmail 11133 invoked from network); 12 Mar 2018 13:21:27 -0000
Received: from us-west-2b.mta.dlp.protect.symantec.com (HELO EUR01-HE1-obe.outbound.protection.outlook.com) (52.33.64.93) by server-10.tower-188.messagelabs.com with AES256-SHA256 encrypted SMTP; 12 Mar 2018 13:21:27 -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; bh=KkOGhHscCwKQ/S/WOsz6HbWvCMzLqTfQJKY8tEtgCbE=; b=HAccVL1QipaJdIUfeKksW3gOIDE6RGniJ2qwTesiN/Qq1zBP2cHRaHPjZFx8Wkm3SfWaNvQWY7Dnc8rFMpE3FG+U4s2hO89YtCzV9zaj9z1oMilFXrsR9YLT40ayMmsBjZgC1PJRP/slwaxOqrP/+ow4LrfoFx1gSsbJ7f0ApJc=
Received: from DB3PR03MB0969.eurprd03.prod.outlook.com (10.161.58.145) by DB3PR03MB249.eurprd03.prod.outlook.com (10.242.131.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.567.12; Mon, 12 Mar 2018 13:21:23 +0000
Received: from DB3PR03MB0969.eurprd03.prod.outlook.com ([fe80::5004:fa8:47e0:8e4d]) by DB3PR03MB0969.eurprd03.prod.outlook.com ([fe80::5004:fa8:47e0:8e4d%13]) with mapi id 15.20.0567.018; Mon, 12 Mar 2018 13:21:23 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: Greg Mirsky <gregimirsky@gmail.com>
CC: "draft-hu-spring-sr-tp-use-case@ietf.org" <draft-hu-spring-sr-tp-use-case@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, "spring@ietf.org" <spring@ietf.org>, Michael Gorokhovsky <Michael.Gorokhovsky@ecitele.com>, Shell Nakash <Shell.Nakash@ecitele.com>, Ron Sdayoor <Ron.Sdayoor@ecitele.com>, Hemmy Yona <Hemmy.Yona@ecitele.com>, Dmitry Valdman <Dmitry.Valdman@ecitele.com>
Thread-Topic: Questions and comments on draft-hu-spring-sr-tp-use-case-01
Thread-Index: AdO5NM5CaFFWfCxwRmGUmzSW6dglcAAXL6yAABzdx6U=
Date: Mon, 12 Mar 2018 13:21:23 +0000
Message-ID: <DB3PR03MB09697742A3F1F221FCFEE7B59DD30@DB3PR03MB0969.eurprd03.prod.outlook.com>
References: <DB3PR03MB09694B9050A01B7735B3FEA59DDC0@DB3PR03MB0969.eurprd03.prod.outlook.com>, <CA+RyBmW00OiCLy7u9U0MNNZ=ybXYVApO0mGUzFgfF31W47RqNA@mail.gmail.com>
In-Reply-To: <CA+RyBmW00OiCLy7u9U0MNNZ=ybXYVApO0mGUzFgfF31W47RqNA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [40.69.43.191]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB3PR03MB249; 7:qDuHdvSwn4yVdUjXRUEMMfOu1G9fc6lhn0SaD8+2weB6Cqn0Ofs+MZ89oBr8BUZ+3ZRr7mPtH8R6e8pLcuGBahe8FXRGtDqVsmFY36Mosn403STTHtOYURuqvjW88NaGoeHSWSz47Px03NJcBqLAtVqK8gz/yIYpktLFZzO2LaSTvkjPm4za4cb65n5k3SRzVM7p0aMzkKtVb3UET7zhCYLeZn6QRSZeOTBkDILKjiZ3KVdJ+0hXrtTaojhHr8FQ
x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: e39644b5-1a3c-4dcf-3086-08d5881c26b8
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:DB3PR03MB249;
x-ms-traffictypediagnostic: DB3PR03MB249:
x-microsoft-antispam-prvs: <DB3PR03MB249BFBF9961AE638F950FFF9DD30@DB3PR03MB249.eurprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(85827821059158)(279101305709854);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231220)(944501244)(52105095)(6055026)(6041310)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:DB3PR03MB249; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB249;
x-forefront-prvs: 06098A2863
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(39860400002)(376002)(366004)(39380400002)(199004)(252514010)(189003)(25584004)(59450400001)(39060400002)(25786009)(86362001)(72206003)(55016002)(3660700001)(4326008)(14454004)(2906002)(7736002)(2900100001)(106356001)(26005)(5250100002)(102836004)(74316002)(478600001)(53546011)(186003)(6506007)(7696005)(76176011)(6436002)(105586002)(6916009)(6116002)(1411001)(2950100002)(3846002)(107886003)(6246003)(81166006)(8936002)(54896002)(6306002)(9686003)(236005)(66066001)(54906003)(53936002)(68736007)(81156014)(606006)(5660300001)(229853002)(316002)(33656002)(8676002)(99286004)(97736004)(3280700002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB249; H:DB3PR03MB0969.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: xEI7rL46u9v8Aupuej/VRmcg72TfI4z9qX0e0kmOHx43xYIZVV7vT94SmxaX54vwjZmkgC9Gy0HSSjlxoBiisw6ooy9WvT+zjbq+ZA43/IDTsrxydBbY8RGgZXAHVRSDbTaWIE8jTf6rwlQ8c1ua5S+k0S5A5og8NQQ8kho7kyWSL15qpMa8DYNMxTvAjaWzzRRB7xko1ClJXYVQ3ou+Jf9veIj52NC9QxSNEydqVrDeJZh5xvZf+SJK3UWX+gDyHJzzPcLpsar1Z8RcZpl34sh3tIQktKBg6SjVlFcKCQtNevXWPvKr/jSUlj6zgVFH+tPEuOYNBJmuLf4q3Vt1kw==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DB3PR03MB09697742A3F1F221FCFEE7B59DD30DB3PR03MB0969eurp_"
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e39644b5-1a3c-4dcf-3086-08d5881c26b8
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2018 13:21:23.1610 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB249
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/i8dajTCBQK1i0KjheyxvStvV48s>
Subject: Re: [mpls] Questions and comments on draft-hu-spring-sr-tp-use-case-01
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 12 Mar 2018 13:21:35 -0000

Greg,
Lots of thanks for a prompt response.
I fully understabd the pressure, and I can surely wait for the answers.

Thumb typed by Sasha Vainshtein

________________________________
From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Monday, March 12, 2018 1:34:51 AM
To: Alexander Vainshtein
Cc: draft-hu-spring-sr-tp-use-case@ietf.org; mpls@ietf.org; spring@ietf.org; Michael Gorokhovsky; Shell Nakash; Ron Sdayoor; Hemmy Yona; Dmitry Valdman
Subject: Re: Questions and comments on draft-hu-spring-sr-tp-use-case-01

Hi Sasha,
the most sincere thanks for your thorough review, thoughtful questions and detailed comments. All are of enormous help and are greatly appreciated.
This is last week before the IETF meeting and, as you know, all are busy preparing for it. We'll discuss your questions and comments and respond during or shortly after the meeting.

Kind regards,
Greg

On Sun, Mar 11, 2018 at 5:50 AM, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>> wrote:
Dear authors of draft-hu-spring-sr-tp-use-case,
I have read the -01 version of the draft, and I find it quite useful as a Use Case document because it helps (at least, me) to formulate and present for discussion several questions dealing with interworking between Segment Routing and MPLS-TP.



1.       In Section 4.1 the draft says that “The centralized controller creates the RIB and synchronizes the forwarding table among segment routing nodes”.

a.       Question: Can you please clarify what exactly does this statement mean?

b.       Comment: From my POV, SR extensions to IGP are enabled and all the nodes in an IGP domain are configured with SRGBs  and various Prefix IDs (including Node SIDs), native SR-MPLS mechanisms inherently set up consistent forwarding plane state without any need in external intervention.

2.       In section 4.3 the draft says that “The SR nodes are assigned the Adjacent SIDs(local SID) by the centralized controller”.

a.       Comment: First of all, Adjacency SIDs are locally significant labels representing IGP adjacencies between the node that assigns them and its IGP neighbors. The same adjacency can be represented by multiple Adjacency SIDs, but each IGP adjacency is represented by at least one Adjacency SID, i.e., these SIDs are not assigned to SR nodes.

b.       Question: As mentioned before, Adjacency SIDs have only local meaning in the forwarding plane of SR-MPLS and therefore they are assigned by each SR node (possibly from its SRLB) and distributed by SR extensions to IGP. So why any intervention from an external controller is required for this purpose? (For the reference, the SR architecture draft<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-15> only says that “The SR architecture allows these SR controllers to discover which SID's are instantiated at which nodes and which sets of local (SRLB) and global labels (SRGB) are available at which node”),.

3.       Also in Section 4.3 “SRTP Strict Constraints Path”, the draft says that “Because there is no label or only the last label in the MPLS label stack when the packet reaches the egress node, the egress node cannot  determine from which ingress node or SR path the packet comes”. It then proposes usage of the Path SID (as defined in the Path Segment in SR-MPLS<https://tools.ietf.org/html/draft-cheng-spring-mpls-path-segment-01> draft) to resolve this issue.

a.       Comment: This statement is obviously correct as written, but, from my POV, it equally applies to SRTP Loose Constraints Paths that are described in Section 4.2 – but usage of Path Segment is not mentioned there, and the label stack of an SRTP Loose Constraints Path shown in Figure 2 does not include Path SID.

b.       Question: Did you consider the need for pairing between the two directions of a bi-directional LSP that uses loose constraints? For the reference, Section 5  of the draft that discusses the need to set up bi-directional SR-TP tunnels and explicitly mentions usage of Path SID for pairing between incoming and outgoing directions of a bi-directional LSP in the end nodes does not differentiate between paths with loose and strict constraints.

4.       RFC 5654 “MPLS-TP Requirements” has defined two options for bi-directional MPLS-TP paths: Co-routed bi-directional LSPs and associated bi-directional LSPs. Therefore two questions:

a.       Are co-routed bi-directional LSPs expected to be supported by the proposed SRTP scheme?

b.       Assuming positive answer to the previous question, is requirement 10 in RFC 5654 pertaining to these LSPs expected to be supported in SRTP?

                                                               i.      Comment: For the reference, this requirement says that “All nodes on the path of a co-routed bidirectional transport path  in the same (sub)layer as the path MUST be aware of the pairing relationship of the forward and the backward directions of the transport path”, i.e., it explicitly requires support of some state per co-routed bi-directional LSP in each transit node. From my POV such awareness contradicts the rationale of Segment Routing

                                                             ii.      Comment: An example of MPLS-TP functionality that builds on such pairing is MPLS-TP Route Tracing as defined in Section 4 of RFC 6426<https://tools.ietf.org/html/rfc6426>. (The current (Apr-2016) version of  the ITU-T Recommendation G.8113.1 leaves Route Tracing for further study).

5.       Both RFC 6427<https://tools.ietf.org/html/rfc6427> and ITU-T recommendation G. 8113.1 define MPLS-TP Alarm Indication Signal (AIS).

a.       Question: Is support of this functionality expected with SRTP?

b.       Comment: While the details of these definitions vary, both require a transit node that detects a failure of the server layer (e.g., a physical link from an upstream node) to inject AIS messages into all client LSPs affected by this failure, i.e. a transit MPLS-TP node is expected to be explicitly aware of all MPLS-TP LSPs that pass thru it.  (Again, from my POV such awareness contradicts the rationale of Segment Routing).

Hopefully these comments and questions will be useful.

Regards,
Sasha

Office: +972-39266302<tel:+972%203-926-6302>
Cell:      +972-549266302<tel:+972%2054-926-6302>
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.
___________________________________________________________________________