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<> 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 
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 

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 

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<>. (The current (Apr-2016) version of  
the ITU-T Recommendation G.8113.1 leaves Route Tracing for further study).

5.       Both RFC 6427<> 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.


Office: +972-39266302
Cell:      +972-549266302


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 
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original 
and all copies thereof.
spring mailing list

Reply via email to