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<https://datatracker.ietf.org/doc/rfc5283/?include_text=1>. 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<https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQahttps:/www.ietf.org/archive/id/draft-ietf-mpls-seamless-mpls-07.txt>
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).
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
