Re: [mpls] [spring] Routing directorate QA review of draft-filsfils-spring-segment-routing-ldp-interop

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Wed, 29 July 2015 13:17 UTC

Return-Path: <Alexander.Vainshtein@ecitele.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0901AC3B6; Wed, 29 Jul 2015 06:17:58 -0700 (PDT)
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, FSL_MY_NAME_IS=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 KfzBa2Y4yuCy; Wed, 29 Jul 2015 06:17:55 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0706.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::706]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E760D1A9236; Wed, 29 Jul 2015 06:17:54 -0700 (PDT)
Received: from DB3PR03MB0780.eurprd03.prod.outlook.com (10.161.55.12) by DB3PR03MB0779.eurprd03.prod.outlook.com (10.161.55.11) with Microsoft SMTP Server (TLS) id 15.1.225.19; Wed, 29 Jul 2015 13:17:35 +0000
Received: from DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) by DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) with mapi id 15.01.0225.018; Wed, 29 Jul 2015 13:17:35 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: "Stefano Previdi (sprevidi)" <sprevidi@cisco.com>
Thread-Topic: [spring] Routing directorate QA review of draft-filsfils-spring-segment-routing-ldp-interop
Thread-Index: AdDJU4roffYaBLXOTjabFYQ9m7cUoAApb99QAAHAcAAAACIm0A==
Date: Wed, 29 Jul 2015 13:17:35 +0000
Message-ID: <DB3PR03MB0780DA324DF1F58D5574C45A9D8C0@DB3PR03MB0780.eurprd03.prod.outlook.com>
References: <DB3PR03MB0780CB9ACC0130DDBDAF32919D8C0@DB3PR03MB0780.eurprd03.prod.outlook.com> <5B43AC77-1C49-407F-90ED-8A35D5D76D88@cisco.com>
In-Reply-To: <5B43AC77-1C49-407F-90ED-8A35D5D76D88@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: cisco.com; dkim=none (message not signed) header.d=none;
x-originating-ip: [109.66.1.206]
x-microsoft-exchange-diagnostics: 1; DB3PR03MB0779; 5:WYrWBIyB7ijOI7VzC8xlwLEKjfCe9VsCngakw8NZ8a13xCdlQdwswszANs4YAhf9bfnl/fPO6AhiS6G2EwbIH0duhYJMU4bhCj1UVAn5Nkh8U3R4w/E+F2917RVo6bQG4azhcy65NmSEMJCY917VOA==; 24:gaWE/tcK3P09UO8VQP0O8u7HzlQgjniOabBvcA5tNnWL9MZ9UdxyLnK+M4mcP3RWpTpIkfG4mYhwsmlsrt9dz/U0SCZpIsjidiwg92tvKU4=; 20:56uUtRGtc/E3Yf6oaIjM8eh+gB8sm39fCbQ3iq7oQbRw7TpX4PAKnKEXiugo8IZtwBdjMoa68RY2SInYoKuhug==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0779;
db3pr03mb0779: X-MS-Exchange-Organization-RulesExecuted
x-microsoft-antispam-prvs: <DB3PR03MB07796D925006BE5DD709B7F29D8C0@DB3PR03MB0779.eurprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DB3PR03MB0779; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0779;
x-forefront-prvs: 0652EA5565
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(24454002)(37854004)(252514010)(66654002)(46102003)(76576001)(66066001)(19580405001)(86362001)(33656002)(54356999)(102836002)(50986999)(2656002)(19580395003)(230783001)(87936001)(555904002)(74316001)(5003600100002)(77156002)(122556002)(62966003)(92566002)(15975445007)(5002640100001)(77096005)(5001920100001)(189998001)(110136002)(2950100001)(5001960100002)(40100003)(76176999)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0779; H:DB3PR03MB0780.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jul 2015 13:17:35.6391 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0779
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/PPfcORcwEC0Fh1KbEYagSZyuQjw>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "spring@ietf.org" <spring@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>, "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>
Subject: Re: [mpls] [spring] Routing directorate QA review of draft-filsfils-spring-segment-routing-ldp-interop
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 29 Jul 2015 13:17:58 -0000

Hi Stefano,
OK by me.

Regards,
Sasha

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


-----Original Message-----
From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] 
Sent: Wednesday, July 29, 2015 4:13 PM
To: Alexander Vainshtein
Cc: rtg-ads@tools.ietf.org; Jonathan Hardwick; rtg-dir@ietf.org; spring@ietf.org; mpls@ietf.org
Subject: Re: [spring] Routing directorate QA review of draft-filsfils-spring-segment-routing-ldp-interop

Hi Sasha,

Many thanks for your review and comments. I'll go through them asap.


Thanks.
s.


On Jul 29, 2015, at 2:52 PM, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> wrote:

> Hi,
> My previous message has been put on hold by the moderator of the SPRING WG as having too many recipients.
> This is partially due to the draft having 12 authors - and  have tried to send the review to each of themJ.
>  
> I am now re-sending it with a shorter (but, hopefully, sufficient - I believe all the authors are on the SPRING mailing list anyway) list of recipients andwith one more issue I have found in the draft - highlighted.
>  
> Regards,
> Sasha
>  
> Office: +972-39266302
> Cell:      +972-549266302
> Email:   Alexander.Vainshtein@ecitele.com
>  
> From: Alexander Vainshtein 
> Sent: Tuesday, July 28, 2015 7:37 PM
> To: 'rtg-ads@tools.ietf.org'
> Cc: bruno.decraene@orange.com; jgs@juniper.net; Jon Hudson; 'Jonathan Hardwick'; 'rtg-dir@ietf.org'.org'; 'spring@ietf.org'.org'; mpls@ietf.org; 'cfilsfil@cisco.com'.com'; 'sprevidi@cisco.com'.com'; 'bashandy@cisco.com'.com'; 'stephane.litkowski@orange.com'.com'; 'Martin.Horneffer@telekom.de'm.de'; 'igormilojevic@telekom.rs'm.rs'; 'rob.shakir@bt.com'.com'; 'saku@ytti.fi'i.fi'; 'wim.henderickx@alcatel-lucent.com'.com'; 'Jeff Tantsura (jeff.tantsura@ericsson.com)'#x27;; 'edward.crabbe@gmail.com'
> Subject: RE: Routing directorate QA review of draft-filsfils-spring-segment-routing-ldp-interop
>  
> Hi,
> My name is Sasha Vainshtein, and  I have been asked to perform the QA review of https://datatracker.ietf.org/doc/draft-filsfils-spring-segment-routing-ldp-interop/.
>  
> Due to health problems I have been very late (but, hopefully, not too late) with this review, and here it is.
>  
> Does the draft solves a real problem? From my POV, definitely yes.
>           1.         The problem stems from the following combination of facts fact that:
> a.       LDP distributes labels for FECs represented by IP prefixes (among other things).
> b.      LDP-based MPLS network are very widely deployed
> c.       SR operating over the MPLS DP allocates labels for SIDs that can represent IP prefixes (again, among other things)
> d.      As a consequence, LDP and SR may effectively map the same IP prefix to different labels.
>           2.         As SR using the MPLS DP is gaining acceptance in the industry, the following deployment scenarios look as realistic to me:
> a.       Coexistence  between LDP-based and SR-based control planes in the same network
> b.      Partial deployment of SR in some sub-domains of a network combined with the operators' need to use the benefits of SR where it is already deployed
> c.       Gradual transition of services  (especially L2 and L3VPN) tunnelled over LDP-created LSPs to LSPs set up using SR (and, possibly, vice versa)
>  
> Is the draft a good enough start for a WG document? From my POV, yes.
> 1         The draft covers multiple (if not all) realistic use cases for coexistence of LDP-based and SR-based control planes and provides  what looks to me as reasonable solutions for these scenarios.
> 2         At the same I would think that additional work is required to complete the work.
>  
> Specific issues with the current draft:
> 1         Editorial: SR-related abbreviations (e.g., SRGB, SID etc.) are used without expansion at the first use, and there is no "Abbreviation" section in the draft.
> 2         Process/Editorial: The draft currently lists 12 authors on its title page exceeding the recommended RFC Editor maximum of 5 authors.
>           3.         Technical: The draft does not analyse the use case  of coexistence between SR and LDP with enabled extension for multi-area LSPs as per RFC 5283. I think that this use case deserves special consideration in the draft because:
> a.       It mentions the use case of seamless MPLS and refers to the (expired) Seamless MPLS Architecture draft
> b.       The seamless MPLS Architecture draft, in its turn, explicitly refers to RFC 5283 in Section 5.1.1 to facilitate binding of labels received via the DoD LDP session while only default route is configured in the RIB of the access node in the seamless MPLS architecture
> c.       It is possible that this use case would not add anything to the draft - but I would prefer to see it in the document with the appropriate explanation
>           4.         Technical: Section 8 "Manageability Considerations" is currently left empty. When this section is written, I would expect at least the following:
> a.       Some level of detail regarding local  policies defining whether LDP-created or SR-created LSPs should be used etc.
> b.      Discussion of using LSP Ping for LSPs that are produced by stitching an LDP segment with an SR one.
> c.       Alternatively, it is possible to move this section to a separate dedicated draft
>           5.         Technical: I think more information should be provided in Section 5 to explain operational aspects of SR-assisted LDP FR:
> a.       In Section 5.1 I would expect the draft to explain that:
>                                                                i.      Node D is selected as the RLFA using the same logic  that is defined for selecting RLFA in RFC 7490
>                                                              ii.      The "bypass LSP" is set up by the SR CP automatically without any need for management intervention
>                                                             iii.      I would like to understand why dynamically set up Targeted LDP sessions are an operational concern. Such sessions appear also when BGP-based auto-discovery for L2VPN is used, and, according to the analysis in RFC 7490, the scalability problems associated with these sessions look as negligible.
> b.      In Section 5.2 I would expect the draft to explain that:
>                                                                i.      The resulting solution is similar to using a bypass LSP to a manually selected RLFA that is set up by RSVP-TE (the difference is that a Targeted LDP session to such an RLFA would be still needed)
>                                                              ii.      Set up of the  "traffic-engineered bypass LSP" by the SR CP is triggered by an appropriate management operation
>                                                             iii.      What information should be provided by the Management Plane for computing the RLFA and the traffic-engineered  bypass LSP? Should it be similar to configuration parameters used with RSVP-TE?
>                                                            iv.      Which kind of logic should be responsible for computing the RLFA and the path to be taken by the engineered bypass LSP: should it be similar to the CSPF used with RSVP-TE?
>                                                              v.      How the traffic-engineered bypass LSP hat is set up by the SR CP would react to additional changes in the network topology (the behaviour of the bypass LSP that is set by RSVP-TE in these situations is well known)
> c.       In both cases it is not clear how the backup label and NHOP are installed:
>                                                                i.      In the FRR with RLFA  as per RFC 7490 this is usually done by LDP that receives the backup label as bound to the destination prefix FEC via the Targeted LDP session, retains it and decides to us it when a route to the destination prefix using the LSP leading to the RLFA as its NHOP is installed in  the RIB as the best route to the destination prefix by IP FRR
>                                                              ii.      This scheme definitely would not work if the Targeted LDP session to the selected RLFA is eliminated
>                                                             iii.      From my POV more details are required here, and the critical question here is, of course, when the scheme proposed in the draft requires any changes in LDP.
>  
>  
> Neither of the issues listed above should be considered as preventing adoption of the draft as a WG document IMO. Actually I think that resolving these issues in the context of a WG document would be more effective.
>  
> Hopefully these notes will be useful.
>  
> Regards,
> Sasha
>  
> Office: +972-39266302
> Cell:      +972-549266302
> Email:   Alexander.Vainshtein@ecitele.com
>  
> From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com] 
> Sent: Wednesday, May 20, 2015 12:46 PM
> To: Alexander Vainshtein
> Cc: bruno.decraene@orange.com; jgs@juniper.net; Alvaro Retana (aretana); Jon Hudson
> Subject: Routing directorate QA review of draft-filsfils-spring-segment-routing-ldp-interop
>  
> Hi Sasha
>  
> Please would you be the routing directorate QA reviewer for draft-filsfils-spring-segment-routing-ldp-interop?
> https://datatracker.ietf.org/doc/draft-filsfils-spring-segment-routing-ldp-interop/
>  
> This initial review has been prompted by the spring WG chairs in parallel with a call for WG adoption.  As such, this document qualifies for "initial QA review".  Please could you provide your initial comments in the next 3 weeks?  As per the QA process, we would also like you to stay with the document and review it again when it goes to WG last call.
>  
> The following web page contains a briefing on the QA process, and guidance for the QA reviewer.
> https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa
>  
> Please copy your comments to the spring and rtgdir mailing lists.
>  
> Please let me know whether you can do it, or not.
>  
> Many thanks
> Jon
>  
>  
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring