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

[Erik Kline via Datatracker <[e-mail]>]

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.

[ 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)?

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

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

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


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


[[ 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)?

[ 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?


[[ nits ]]

[ section 6 ]

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