Re: [spring] Intdir telechat review of draft-ietf-spring-srv6-network-programming-18

["Pablo Camarillo (pcamaril)" <[e-mail]>]

Hi Brian,

Many thanks for your thorough review. Please see inline with [PC].

Cheers,
Pablo.

-----Original Message-----
From: Brian Haberman via Datatracker <[e-mail]> 
Sent: lunes, 14 de septiembre de 2020 20:51
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Intdir telechat review of draft-ietf-spring-srv6-network-programming-18

Reviewer: Brian Haberman
Review result: On the Right Track

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.

[PC] Thanks for this comment, indeed the summary needs some improvement to identify that the node processing the SID is the segment endpoint node, not a transit node.  Also note that ‘SR Segment Endpoint Node’ and ‘Transit Node’ are defined in this document's terminology section.
<OLD>
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.
</OLD>
<NEW>
When an SRv6 SID is in the Destination Address field of an IPv6
   header of a packet, it is routed through Transit Nodes in an IPv6 network as an IPv6
   address.

   Its processing at a SR Segment Endpoint Node is defined in [RFC8754] section 4.3 and reproduced
   here as a reminder.
</NEW>

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.

[PC] Recall that an SR Segment Endpoint node is the only node installing FIB entries for the SIDs it instantiates. 
No Transit Node needs to discover L, in fact it does not need to know anything about the SIDs instantiated at SR segment endpoint nodes.  It only needs to be able to route packets destined to an address covered by L toward the SR Segment Endpoint node instantiating SIDs within L.  A transit node needs to discover neither F nor A for the same reason.

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?

[PC] Section 3.2 discusses some of these considerations that include use of both global unicast and ULA spaces. The application of source-route concept to multicast is outside the scope of RFC8402 and hence outside the scope of this document as well.

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?

[PC] I don’t think this limits the types of behaviors that can be implemented, but it calls out something that should be considered for behavior definition.  If a behavior is defined in a future document that changed ARG within a flow, then it should describe how and why that is OK.

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.

[PC] These examples were added based on specific requests received for providing illustrations (based on practical inputs from operators who have deployed SRv6) on how SID allocation and addressing may be done. We believe they bring value and hence should remain, but if IESG prefers to move it in an appendix, we will do it of course.

What constitutes a “remote node”?

[PC] Good catch, indeed, the right term in that particular text is “SR Source Node”. I’ll replace that.

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.

[PC] Good to recall on section 4. I’ll add this text.

<OLD>
Section 4.16 defines flavors of some of these behaviors.
</OLD>
<NEW>
Section 4.16 defines flavors of some of these behaviors.

Section 9.2 of this document defines the IANA Registry used to maintain all these behaviors as well as future ones defined in other documents.
</NEW>


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,
[PC] RFC8754 (sec 4.3.1) specified a single SRv6 SID processing behavior (Code point 32767 in the table 4 of this document). This document specifies several other SRv6 SID behaviors in its Sec 4.

 Section 4.3.1.1. RFC8754 seems to only create an SRH in an encapsulating header (i.e., no SRH insertion). Why does this draft specify SRH removal?
[PC] The motivation and use-case for defining this behavior is provided in 4.16.1.3.

Section 5.1
- - - - - -

What is the relationship between node N and the address T used as the source address of the encapsulating header?
[PC] Indeed, good to call out. I propose the following diff. Does it address your concern ?

<OLD>
   N steers the transit packets P1 and P2 into an SR Policy with a
   Source Address T and a Segment list <S1, S2, S3>.
</OLD>
<NEW>
   Node N is configured with an IPv6 Address T (e.g. to its loopback interface).

   N steers the transit packets P1 and P2 into an SR Policy with a
   Source Address T and a Segment list <S1, S2, S3>.
</NEW>

Section 6
- - - - -

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

[PC] Thanks, in fact there is no need for that section at all, so let's promote the subsections

Section 7
- - - - -

Is there a security issue if a SID is used as a source address?
[PC] This document does not specify nor discuss the use of SID as a source address; however I see no security issue if they are used that way .

Should any part of the prefix being used for SIDs be advertised to external peers/networks?
[PC] There is no requirement to advertise the prefix being used for SIDs to external peers/networks outside the SR Domain.