[spring] Questions and comments on draft-hu-spring-sr-tp-use-case-01

[Alexander Vainshtein <[e-mail]>]

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: [phone]
Cell:      [phone]
Email:   [e-mail]


___________________________________________________________________________

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