Re: [RTG-DIR] Routing directorate telechat review of draft-ietf-spring-segment-routing-13

["Les Ginsberg (ginsberg)" <[e-mail]>]

Sasha –

Inline.

From: Alexander Vainshtein [mailto:[e-mail]]
Sent: Tuesday, December 12, 2017 8:17 AM
To: Jonathan Hardwick <[e-mail]>; [e-mail]; Alvaro Retana <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; Michael Gorokhovsky <[e-mail]>; Alexander Ferdman <[e-mail]>
Subject: RE: Routing directorate telechat review of draft-ietf-spring-segment-routing-13
Importance: High

Jon (and all),
Your review has triggered for me a question (that probably should be asked earlier) that deals exactly with the issue of the per-algorithm NH selection:

-          Suppose that IGP advertises a certain Prefix-SID. Suppose also that it is advertised with one of the “shortest path-based” algorithms defined in Section 3.1.1 of the draft

-          Does any of these algorithms require exact match with the original prefix in the Prefix-SID for selection of the NH (as in the case of LDP as per RFC 5063), or would the longest prefix match (as in the case of LDP extension for multi-area LSPs<https://tools.ietf.org/html/rfc5283>) do?

I have not found so far an explicit answer to this question – nether in this draft, nor in any other applicable SPRING WG document.

My reading of the SR-LDP Interop draft<https://tools.ietf.org/html/draft-ietf-spring-segment-routing-ldp-interop-09> suggests that at least by default exact match should be  used in SR – otherwise operation of the mapping server defined in this document would become quite problematic.  But this is just a guess.

What (if anything) did I miss?

[Les:] I am not appreciating why you are confused – so perhaps I do not fully understand your question – but let me take a stab.

If we are talking about SR-MPLS, then forwarding is done by label match – not by longest match lookup.
If we are talking about SRv6, because SIDs are IPv6 addresses, it is possible to support SRv6 with longest match lookup. Indeed, this is one of the nice properties of SRv6 because it means not all nodes in the network have to be upgraded to support SRv6. To legacy nodes a SID simply looks like an IPv6 address and it can use legacy forwarding logic. https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-02#section-3 may be helpful here.

   Les


Regards,
Sasha

Office: [phone]
Cell:      [phone]
Email:   [e-mail]<mailto:[e-mail]>

From: rtg-dir [mailto:[e-mail]] On Behalf Of Jonathan Hardwick
Sent: Tuesday, December 12, 2017 4:20 PM
To: [e-mail]<mailto:[e-mail]>; Alvaro Retana <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: [RTG-DIR] Routing directorate telechat review of draft-ietf-spring-segment-routing-13

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Document: draft-ietf-spring-segment-routing-13.txt
Reviewer: Jon Hardwick
Review Date: 12 December 2017
IETF LC End Date: 30 November 2017
Telechat date: 14 December 2017
Intended Status: Standards Track

Summary
No issues found. This document is ready for publication.

Comments
This document is very well written and is easy to understand.  It serves as a good introduction to, and overview of, the segment routing architecture.  It includes a guide to the operation of the control plane and the MPLS and IPv6 data planes and gives references to the appropriate documents which standardize the necessary control and data plane extensions.  I found no issues and believe the document is ready to be published.  I noted one minor clarification which the ADs may wish to make to the document before it is published – see below.

Major Issues
No major issues found.

Minor Issues
Section 3.1 discusses the prefix SID.  Section 3.1.1 introduces the concept of an algorithm that is to be used by an SR-capable router in selecting the correct next hop to use when executing a forwarding instruction on a Prefix SID.  Section 3.1.2 explains how per-algorithm forwarding is to be applied in the MPLS data plane, but section 3.1.3 does not mention per-algorithm forwarding in the context of IPv6.  It would be better to have an explicit statement in 3.1.3, as currently the reader may wonder whether per-algorithm forwarding is intended to be applied in the IPv6 data plane.

Also, section 3.1.3 says “any remote IPv6 node will maintain a plain IPv6 FIB entry for any prefix, no matter if the represent a segment or not. This allows forwarding of packets to the node which owns the SID even by nodes which do not support Segment Routing.”  Clearly, a node that does not understand that an IPv6 address represents a SID will be unable to apply per-algorithm forwarding reliably. In my opinion, section 3.1.3 could note this restriction more clearly.

Nits
Note also the nit in the section 3.1.3 text I quoted above: “no matter if the represent a segment or not” -> “whether or not the prefix represents a segment”.


___________________________________________________________________________

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