Skip to main content

Telechat Review of draft-ietf-spring-srv6-network-programming-18
review-ietf-spring-srv6-network-programming-18-intdir-telechat-haberman-2020-09-14-00

Request Review of draft-ietf-spring-srv6-network-programming
Requested revision No specific revision (document currently at 28)
Type Telechat Review
Team Internet Area Directorate (intdir)
Deadline 2020-09-22
Requested 2020-09-11
Requested by Éric Vyncke
Authors Clarence Filsfils , Pablo Camarillo , John Leddy , Daniel Voyer , Satoru Matsushima , Zhenbin Li
Draft last updated 2020-09-14
Completed reviews Opsdir Last Call review of -17 by Dan Romascanu (diff)
Tsvart Last Call review of -17 by Mirja Kühlewind (diff)
Secdir Last Call review of -17 by Brian Weis (diff)
Secdir Telechat review of -19 by Brian Weis (diff)
Intdir Telechat review of -18 by Brian Haberman (diff)
Secdir Telechat review of -20 by Brian Weis (diff)
Comments
This is quite a long document but I would appreciate a review by the int-dir even if this protocol will probably mainly be used with a domain.
Thank you
-éric
Assignment Reviewer Brian Haberman
State Completed
Review review-ietf-spring-srv6-network-programming-18-intdir-telechat-haberman-2020-09-14
Posted at https://mailarchive.ietf.org/arch/msg/int-dir/m_guR84Z7D_orFugpKB8-2PD0eg
Reviewed revision 18 (document currently at 28)
Result On the Right Track
Completed 2020-09-14
review-ietf-spring-srv6-network-programming-18-intdir-telechat-haberman-2020-09-14-00
Section 3
- - - - - - -

The abbreviated description of the section is a bit confusing related to FIB
lookup. This text:

   When an SRv6 SID is in the Destination Address field of an IPv6
   header of a packet, it is routed through an IPv6 network as an IPv6
   address.

   Its processing is defined in [RFC8754] section 4.3 and reproduced
   here as a reminder.

makes it sound like all FIB lookups are being done on SIDs whereas the text in
8754, section 4.3 is much clearer that the lookups occur on IPv6 addresses and
that some may be SIDs.

Section 3.1
- - - - - -

   This document defines an SRv6 SID as consisting of LOC:FUNCT:ARG,
   where a locator (LOC) is encoded in the L most significant bits of
   the SID, followed by F bits of function (FUNCT) and A bits of
   arguments (ARG).  L, the locator length, is flexible, and an operator
   is free to use the locator length of their choice.  F and A may be
   any value as long as L+F+A <= 128.  When L+F+A is less than 128 then
   the remainder of the SID MUST be zero.

Does a system outside of the SR Ingress Node need to discover L? If so, is it
derived from seeing a FIB entry for LOC? How does the a system determine the
length of F and A? By comparing FIB entries for LOC and LOC:FUNCT (that is what
I infer from section 3.2)? The parsing rules seem incomplete and can lead to
behavior that is non-deterministic. The same can be said for B:N.

What are the guidelines for choosing LOC (or B)? Does this come strictly out of
the unicast address space? ULA space? Does this spec support LOC being
allocated out of multicast space?

The following text seems rather limiting:

     The ARG value of a routed SID SHOULD remain constant among packets in
     a given flow.  Varying ARG values among packets in a flow may result
     in different ECMP hashing and cause re-ordering.

If ARG needs to stay constant, does this limit the types of functions that can
be implemented using this technique?

Section 3.2
- - - - - -

The various paragraphs that describe “example deployments” really don’t belong
in a standards track document. If they are needed to explain the approach, then
the description of the approach is incomplete. The reader should not have to
infer functionality by parsing example uses. If the examples remain, I suggest
they be put in an informative appendix.

What constitutes a “remote node”?

Section 4
- - - - -

I would suggest either mentioning that these behaviors are managed via an IANA
registry or I would add a forward pointer to the IANA Considerations section.

Section 4.16.1.2
- - - - - - - -

The steps described to process the SRH (i.e., instruction S14.4) is different
from the process described for SRH processing in RFC 8754, Section 4.3.1.1. RFC
8754 seems to only create an SRH in an encapsulating header (i.e., no SRH
insertion). Why does this draft specify SRH removal?

Section 5.1
- - - - - -

What is the relationship between node N and the address T used as the source
address of the encapsulating header?

Section 6
- - - - -

This section could use some introductory text to explain what is meant by an
Operation.

Section 7
- - - - -

Is there a security issue if a SID is used as a source address?

Should any part of the prefix being used for SIDs be advertised to external
peers/networks?