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

[Greg Mirsky <[e-mail]>]

Hi Sasha,
the most sincere thanks for your thorough review, thoughtful questions and
detailed comments. All are of enormous help and are greatly appreciated.
This is last week before the IETF meeting and, as you know, all are busy
preparing for it. We'll discuss your questions and comments and respond
during or shortly after the meeting.

Kind regards,
Greg

On Sun, Mar 11, 2018 at 5:50 AM, Alexander Vainshtein <
[e-mail]> wrote:

> 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] <+972%203-926-6302>
>
> Cell:      [phone] <+972%2054-926-6302>
>
> 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.
> ____________________________________________________________
> _______________
>