Re: [spring] Éric Vyncke's No Objection on draft-ietf-spring-srv6-network-programming-19: (with COMMENT)

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

Hi Éric,

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

Regards,
Pablo.

-----Original Message-----
From: Éric Vyncke via Datatracker <[e-mail]> 
Sent: martes, 22 de septiembre de 2020 21:20
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; Bruno Decraene <[e-mail]>; Joel Halpern <[e-mail]>; [e-mail]; [e-mail]
Subject: Éric Vyncke's No Objection on draft-ietf-spring-srv6-network-programming-19: (with COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-spring-srv6-network-programming-19: No Objection

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/



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

Thank you for the work put into this document.

Thank you also for having edited the document based on the INT-DIR review by Brian Haberman (thank you Brian for the detailed review!) and replying to Brian's review.
https://datatracker.ietf.org/doc/review-ietf-spring-srv6-network-programming-18-intdir-telechat-haberman-2020-09-14/

Please find below a couple of non-blocking COMMENT points and nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==
-- Section 3 --
There is some text copied from section 4.3 from RFC 8754. But, even if it seems obvious that the behaviors specified in this document _ONLY_ apply when "A FIB entry that represents a locally instantiated SRv6 SID", I suggest to spell it out to avoid any ambiguity.
[PC] Agreed. I suggest the following couple of diffs
<OLD>
      - No Match

   This document formally defines behaviors and parameters for SRv6
   SIDs.
   
3.1.  SID Format
</OLD>
<NEW>
      - No Match

Section 4 of this document defines a new set of SRv6 SID behaviors in
   addition to that defined in RFC8754 Section 4.3.1.

3.1.  SID Format
</NEW>
<OLD>
   The list is not exhaustive.  In practice, any function can be
   attached to a local SID: e.g. a node N can bind a SID to a local VM
   or container which can apply any complex processing on the packet.

   The following sub-sections detail the behaviors, introduced in this
   document, that a node (N) binds to a SID (S).

   The pseudocode describing ….
</OLD>
<NEW>
   The list is not exhaustive.  In practice, any function can be
   attached to a local SID: e.g. a node N can bind a SID to a local VM
   or container which can apply any complex processing on the packet.

   When an SRv6-capable node (N) receives an IPv6 packet whose destination
   address matches a FIB entry that represents a locally instantiated SRv6
   SID (S), the IPv6 header chain is processed as defined in Section 4 of
   [RFC8200]. For SRv6 SIDs associated with an Endpoint Behavior defined in
   this document, the SRH and Upper layer header are processed as defined
   in the following subsections.

   The pseudocode describing ….
</NEW>

-- Section 3.2 --
I am a little ambivalent with Brian's point about the location of the given examples. On one hand, those real case examples of SID allocation are really helpful to understand the impact of allocation; on the other hand, it is usual to move examples in appendix. Curious to see if other IESG members have other point of view.
[PC] Sure. We will wait for other IESG members to share their views.

In the last short example (this one could stay in the current location), should the value of F and A be stated? They are obvious from the used SID value of course, but, let's be complete ?
[PC] Indeed. Added for next rev.

-- Section 3.3 --
Please follow RFC 5952 and write all IPv6 in lowercase.
[PC] Ack. Fixed for next rev.

-- Section 4.2 and 4.3 --
As "End.X" and "End.T" behaviors are variants of the "End" behavior, does the section 4.1.1 (Upper-Layer Header) also apply ?
[PC] End.X and End.T share the same Upper-layer Header processing as the End behavior. This is not mentioned neither in 4.2 or 4.3, so I’ll add a note on both of them to be explicit.
<OLD>
   When the End.X behavior is associated with a BGP Next-Hop, it is the
   SRv6 instantiation of the BGP Peering Segments [RFC8402].

4.3.  End.T: Specific IPv6 Table Lookup
</OLD>
<NEW>
   When the End.X behavior is associated with a BGP Next-Hop, it is the
   SRv6 instantiation of the BGP Peering Segments [RFC8402].

   When processing the Upper-layer Header of a packet matching a FIB
   entry locally instantiated as an SRv6 End.X SID, process the packet
   as per Section 4.1.1.

4.3.  End.T: Specific IPv6 Table Lookup
</NEW>
[PC] The same note will be added for End.T (4.3).

-- Section 4.9 --
For consistency with previous behavior descriptions of End.DT[46], I suggest to mention that 143 has been reserved by IANA.
[PC] Ack. Fixed for next rev.

== NITS ==
-- Section 2 --
In the bullet list, there are a couple of missing '.' at the end of the list items.
[PC] Ack. Fixed for next rev.

-- Section 3 --
"longest-prefix-match lookup on the packets destination address" "packets"
should probably be singular.
[PC] Ack. I believe correct is “packet’s”.

In "IPv6 subnet allocated for SRv6 SIDs by the operator", should it rather be "prefix" than "subnet" ?
[PC] Ack. Fixed for next rev.

-- Section 3.2 --
Strongly suggest to be consistent with the use of "IANA Endpoint Behavior codepoint" as sometimes it is shortened into "IANA Behavior" (also unsure whether the "IANA" qualification is really useful here)
[PC] Ack. Fixed for next rev to “SRv6 Endpoint Behavior codepoint”

-- Section 4.2 --
"one for the bundle(LAG)" Link Aggregation has not been expanded before and I am not sure whether the 'LAG' adds anything to the paragraph.
[PC] Ack. LAG removed.

-- Section 4.16 --
Should PSP, USP, USD be expanded in the short introduction of this section ?
[PC] Ack. Added for next revision.

-- Section 8 --

The usual location of the security considerations is after all specification section, so, it should be after the 'control plane' section.
[PC] Ack. Section moved.