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
Cell: +972-549266302
Email: alexander.vainsht...@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.
__________________________________________________________________________________________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
