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

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

Hi Eric,

Please see inline with [PC2].

Thanks,
Pablo.

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

Pablo,

Thank you for your reply. See inline for EV>

-éric

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

    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>

EV> Good for me

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

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

    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.

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)
[PC2] Added in rev21. 

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

EV> thanks

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

EV> fine for me

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

EV> OK

    == 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.
EV> OK
    -- Section 3 --
    "longest-prefix-match lookup on the packets destination address" "packets"
    should probably be singular.
    [PC] Ack. I believe correct is “packet’s”.
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.
[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.

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

EV> Thanks

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

EV> OK

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


EV> OK

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


EV> OK

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


EV> OK