Re: [spring] Erik Kline's Discuss on draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT)

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

Hi Erik,

Thank you for your review. Please see inline with [PC].

Regards,
Pablo.

-----Original Message-----
From: Erik Kline via Datatracker <[e-mail]> 
Sent: jueves, 24 de septiembre de 2020 8:41
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; Bruno Decraene <[e-mail]>; Joel Halpern <[e-mail]>; [e-mail]
Subject: Erik Kline's Discuss on draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT)

Erik Kline has entered the following ballot position for
draft-ietf-spring-srv6-network-programming-20: Discuss

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I support Alvaro's and others' discuss points.  I have only a few points that I think are easily cleared.

[ section 3.2 ]

* I'm a bit concerned about this first example, as it might give the mistaken
  impression that fc00::/7 is free for anyone to carve up as they wish
  (I say this regardless of what this operator may or may not have done).

  Per 4193, operators are supposed to generate random /48s from fd00::/8.

  I think this is easily corrected though, and I'd suggest:

  OLD:

  .....  The provider historically deployed IPv6 and assigned
  infrastructure addresses from a portion of the fc00::/7 prefix.  They
  further subdivided the prefix into three /48 prefixes (Country X,
  Country Y, Country Z) to support their SRv6 infrastructure.  From
  those /48 prefixes each router is assigned a /64 prefix from which
  all SIDs of that router are allocated.

  NEW:

  .....  The provider historically deployed IPv6 and assigned
  infrastructure addresses from ULA space [RFC 4193].  They specifically
  allocated three /48 prefixes (Country X, Country Y, Country Z) to
  support their SRv6 infrastructure.  From those /48 prefixes each router
  was assigned a /64 prefix from which all SIDs of that router are allocated.
[PC] Ack. Replaced text with your suggestion in rev21.

[ section 4.16.2 ]

* I'm not sure I understand what the value of specifying USP is.  This looks
  to me like an implementation detail and seems unnecessary.  In all cases
  where the S03 code block is entered it's the processing of the remainder of
  the inner packet that's important, I would think.

  I guess, what's the value of specifying the way in which an implementation
  can begin to process the next header?  Is this for chained SRHs and thus
  resubmitting the inner SRH to the same SID processing (8200 says that the
  RH 'should appear at most once', but that's as strong as the text gets)?

[PC] We have use-cases where the packets with SRH may be destined to applications or host implementations running in containers. The USP flavor is useful to remove the consumed SRH from the extension header chain before sending over to the application stack – we’ve seen this with smartNICs. As such the perspective on externally observability may differ and hence we believe it is needed to specify this.

[ section 4.16.3 ]

* This too seems like an implementation detail, and it's not clear what it's
  adding to the document.  But I must be misunderstanding something.

[PC] The USD flavor specifically enables the de-encapsulation of inner IP packet and its further forwarding (consider use-case like TI-LFA where encapsulation is done on the PLR and de-encapsulation has to be done on the last node of the repair list). In this case the PLR node that is crafting the SID list wants to ensure that the last segment in the repair list is able to perform decapsulation.

[ section 7 ]

* What flow label is included in hashing where End.DX4 is concerned?  If
  it's the flow label of the outermost IPv6 header, then the same question
  comes to mind for End.X and End.DX6; I'd assumed it would be the inner
  packet's flow label (and src/dst addresses) that would factor into the
  flow hashing.

[PC] Ingress PE, upon encapsulation of the received customer packet via H.Encap, computes and sets the IPv6 Flow Label of the new IPv6 header as described in RFC6437.
Upon End.X, End.DX6 or End.DX4 we use the IPv6 Flow Label of the outer IPv6 header (that was computed by the ingress PE).
I’ve clarified this in Section 7 with the following diff:
<OLD>
   When a flow-based selection within a set needs to be performed, the
   source address, the destination address and the flow label MUST be
   included in the flow-based hash.
</OLD>
<NEW>
   When a flow-based selection within a set needs to be performed, the
   IPv6 Source Address, the IPv6 Destination Address and the IPv6 Flow Label of the outer IPv6 header MUST be included in the flow-based hash.
</NEW>

[ section 8 ]

* Of what value to the ingress node is knowledge of USP or USD behaviour
  at the terminus?  That still seems like exposing an implementation detail.

[PC] In order to achieve both of the use-cases described above. As an example, if a P router only has a SID instantiated with the End behavior (0x0001), then such SID and hence such node cannot be used in the TILFA backup path. It needs to support USD to be able to be used.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

[[ comments ]]

[ section 3.2 ]

* First, thanks for adding this section; I think it does help.

* Second, thanks for clarifying that Endpoint Behaviour cannot be inferred
  from FUNCT; much improved.

[PC] Thanks for your feedback that originated this section. :-)

[[ questions ]]

[ section 4 ]

* When an SRv6-capable node receives a packet destined to a locally
  instantiated SID, doesn't it also apply RFC 8754 processing
  (as well as RFC 8200)?
[PC] Yes.  Section 4 does mention that the extension header is processed as defined by RFC8200; and the SRH processing, when the FIB entry represents a locally instantiated SRv6 SID, is processed as defined by the SID behavior. RFC8754 section 4.3.1 defines a single SID behavior. This document specifies other SID behaviors.
Note that this document defines an SRv6 Endpoint Behavior codepoint for the RFC8754 SID behavior. 
In revision 20 this document we also includes the following note in section 3.
   Section 4 of this document defines a new set of SRv6 SID behaviors in
   addition to that defined in [RFC8754] Section 4.3.1.

[ section 4.9 ]

* Can an End.DX2 sID be associated with LAG'd set of outgoing interfaces J,
  analogous to the "interface bundle" description for End.X processing?

[PC] Agreed. Added in rev21.

[[ nits ]]

[ section 6 ]

* "pair of traffic counter" -> "pair of traffic counters"

[PC] Ack. Fixed in rev21.

Thank you for your time.