Dear authors of draft-cheng-spring-mpls-path-segment-01, and I have a few
1. From my POV, the draft addresses the problem of identifying an
incoming SR LSP at the tail-end node.
a. This problem is real because SR LSPs, by their very nature, are MP2P
b. The draft does not try to solve the problem of SR LSP identification
in transit nodes.
2. The draft proposes two solutions (one-label and two-label) for the
above-mentioned problem, and the authors expect the WG to discuss these
solutions and to select the preferred one. As I see it:
a. Both uses cases discussed in Section 3 of the draft can be addressed
with any of these solutions
b. IMHO and FWIW, as long as SR-MPLS leaves multicast out of scope (as
mentioned in Section 6 of the SR
draft), any future issue with identification of SR LSPs that can be addressed
with the two-label solution can also be addressed with the one-label solution
c. The two-label solution requires support of upstream-allocated labels
and context-specific label spaces, i.e., adds substantial implementation
complexity. The one-label solution can be implemented using just per platform
label space of downstream-allocated labels.
d. Based on these considerations, my preference (FWIW) is for one-label
3. The draft lists both the already mentioned SR Architecture draft and
draft as Informative references, but the SRV6 Routing
draft appears as a Normative reference. From my POV, the first two documents
MUST be Normative references and the last one - an Informative reference,
because the draft only deals with SR-MPLS.
Hopefully, these notes can be useful.
This e-mail message is intended for the recipient only and contains information
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received
transmission in error, please inform us by e-mail, phone or fax, and then
delete the original
and all copies thereof.
spring mailing list