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 <[email protected]> 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: [email protected] > > From: Alexander Vainshtein > Sent: Tuesday, July 28, 2015 7:37 PM > To: '[email protected]' > Cc: [email protected]; [email protected]; Jon Hudson; 'Jonathan > Hardwick'; '[email protected]'; '[email protected]'; [email protected]; > '[email protected]'; '[email protected]'; '[email protected]'; > '[email protected]'; '[email protected]'; > '[email protected]'; '[email protected]'; '[email protected]'; > '[email protected]'; 'Jeff Tantsura > ([email protected])'; '[email protected]' > 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: [email protected] > > From: Jonathan Hardwick [mailto:[email protected]] > Sent: Wednesday, May 20, 2015 12:46 PM > To: Alexander Vainshtein > Cc: [email protected]; [email protected]; 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 > [email protected] > https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
