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

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Tue, 22 Sep 2020 12:19:49 -0700

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

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

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 ?

-- Section 3.3 --
Please follow RFC 5952 and write all IPv6 in lowercase.

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

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

== NITS ==
-- Section 2 --
In the bullet list, there are a couple of missing '.' at the end of the list
items.

-- Section 3 --
"longest-prefix-match lookup on the packets destination address" "packets"
should probably be singular.

In "IPv6 subnet allocated for SRv6 SIDs by the operator", should it rather be
"prefix" than "subnet" ?

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

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

-- Section 4.16 --
Should PSP, USP, USD be expanded in the short introduction of this section ?

-- Section 8 --

The usual location of the security considerations is after all specification
section, so, it should be after the 'control plane' section.

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 23 Sep 2020 16:20:16 +0000

Hi Éric,

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

Regards,
Pablo.

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

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

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/

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.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 24 Sep 2020 10:16:25 +0000

Pablo,

Thank you for your reply. See inline for EV>

-éric

-----Original Message-----
From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wednesday, 23 September 2020 at 18:20
To: Eric Vyncke <[email-masked]>, The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Bruno Decraene <[email-masked]>, Joel Halpern <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Éric Vyncke's No Objection on draft-ietf-spring-srv6-network-programming-19: (with COMMENT)

    Hi Éric,

    Regards,
    Pablo.

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

    Regards,

    -éric

    == COMMENTS ==
    -- Section 3 --

    3.1.  SID Format
    </OLD>
    <NEW>
          - No Match

    3.1.  SID Format
    </NEW>
    <OLD>

EV> Good for me

    -- Section 3.2 --

EV> It looks like Brian and I are the only ones, so, leave the examples where they are

EV> Humm I would be even more explicit by stating that F=16 and A=foo (and the latter is ignored in this example as there is no argument)

    -- Section 3.3 --

EV> thanks

EV> fine for me

    -- Section 4.9 --

EV> OK

    == NITS ==
    -- Section 2 --
EV> OK
EV> unsure whether the genitive case applies to objects/concepts. My English teacher told me 'only for people'. But, RFC editor will fix it if required.

EV> Thanks

    -- Section 3.2 --

EV> OK

    -- Section 4.2 --

EV> OK

    -- Section 4.16 --

EV> OK

    -- Section 8 --

EV> OK

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Fri, 25 Sep 2020 18:30:50 +0000

Hi Eric,

Please see inline with [PC2].

Thanks,
Pablo.

-----Original Message-----
From: Eric Vyncke (evyncke) <[email-masked]> 
Sent: jueves, 24 de septiembre de 2020 12:16
To: Pablo Camarillo (pcamaril) <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Bruno Decraene <[email-masked]>; Joel Halpern <[email-masked]>; [email-masked]
Subject: Re: Éric Vyncke's No Objection on draft-ietf-spring-srv6-network-programming-19: (with COMMENT)

Pablo,

-éric

-----Original Message-----
From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wednesday, 23 September 2020 at 18:20
To: Eric Vyncke <[email-masked]>, The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Bruno Decraene <[email-masked]>, Joel Halpern <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Éric Vyncke's No Objection on draft-ietf-spring-srv6-network-programming-19: (with COMMENT)

    Hi Éric,

    Regards,
    Pablo.

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

    Regards,

    -éric

    == COMMENTS ==
    -- Section 3 --

    3.1.  SID Format
    </OLD>
    <NEW>
          - No Match

    3.1.  SID Format
    </NEW>
    <OLD>

EV> Good for me

    -- Section 3.2 --

[PC2] Added in rev21. 

    -- Section 3.3 --

EV> thanks

EV> fine for me

    -- Section 4.9 --

EV> OK

    == NITS ==
    -- Section 2 --
[PC2] I've kept the same wording as in RFC8754, which is "packet's", but I'm not sure about it. RFC editor will indeed fix if needed. Thanks.

EV> Thanks

    -- Section 3.2 --

EV> OK

    -- Section 4.2 --

EV> OK

    -- Section 4.16 --

EV> OK

    -- Section 8 --

EV> OK

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 28 Sep 2020 21:25:45 +0000

Pablo,

Thank you for the -22 as it fixes my last open comment.

Regards

-éric

-----Original Message-----
From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Friday, 25 September 2020 at 20:30
To: Eric Vyncke <[email-masked]>, The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Bruno Decraene <[email-masked]>, Joel Halpern <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Éric Vyncke's No Objection on draft-ietf-spring-srv6-network-programming-19: (with COMMENT)

    Hi Eric,

    Thanks,
    Pablo.

    -----Original Message-----
    From: Eric Vyncke (evyncke) <[email-masked]> 
    Sent: jueves, 24 de septiembre de 2020 12:16
    To: Pablo Camarillo (pcamaril) <[email-masked]>; The IESG <[email-masked]>
    Cc: [email-masked]; [email-masked]; [email-masked]; Bruno Decraene <[email-masked]>; Joel Halpern <[email-masked]>; [email-masked]
    Subject: Re: Éric Vyncke's No Objection on draft-ietf-spring-srv6-network-programming-19: (with COMMENT)

    Pablo,

    -éric

    -----Original Message-----
    From: "Pablo Camarillo (pcamaril)" <[email-masked]>
    Date: Wednesday, 23 September 2020 at 18:20
    To: Eric Vyncke <[email-masked]>, The IESG <[email-masked]>
    Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Bruno Decraene <[email-masked]>, Joel Halpern <[email-masked]>, "[email-masked]" <[email-masked]>
    Subject: RE: Éric Vyncke's No Objection on draft-ietf-spring-srv6-network-programming-19: (with COMMENT)

        Hi Éric,

        Regards,
        Pablo.

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

        Regards,

        -éric

        == COMMENTS ==
        -- Section 3 --

        3.1.  SID Format
        </OLD>
        <NEW>
              - No Match

        3.1.  SID Format
        </NEW>
        <OLD>

    EV> Good for me

        -- Section 3.2 --

        -- Section 3.3 --

    EV> thanks

    EV> fine for me

        -- Section 4.9 --

    EV> OK

        == NITS ==
        -- Section 2 --

    EV> Thanks

        -- Section 3.2 --

    EV> OK

        -- Section 4.2 --

    EV> OK

        -- Section 4.16 --

    EV> OK

        -- Section 8 --

    EV> OK