Subject: Re: John Scudder's Discuss on draft-ietf-6man-spring-srv6-oam-11: (with DISCUSS and COMMENT)

From: John Scudder <[email-masked]>
Date: Thu, 13 Jan 2022 19:13:09 +0000

Hi Zafar.

(Top-posting rather than inlining.)

Regarding my DISCUSS where I suggested splitting the document, I agree that doing so would represent administrative overhead. However I continue to believe that it’s desirable that the document be clear about what portions implementors do, and do not, need to care about. 

Suppose we moved Section 3 to an appendix? We commonly use appendices in our document set to make it obvious that certain material, while it does provide additional information for interested readers, doesn’t need to be attended to by those wanting to consume only the meat of the spec. The move would obviously result in a large line count in the diff, but that’s just a mechanical issue, not really a problem.

Regarding the rest of your updates, the only one I found that doesn’t seem fully resolved is the “classic” thing (point 5). There are a few remaining occurrences, in §3.2.1 and §3.2.2 (“IPv6 classic” and “classic traceroute”). 

Regards,

—John

> On Nov 29, 2021, at 1:49 AM, Zafar Ali (zali) <[email-masked]> wrote:
> 
> 
> 
> Hi John,  
>  
> Many thanks for your detailed review, excellent comments and suggestions; highly appreciated!
> I am sorry for the late follow-up on these comments (due to some personal reasons)
>  
> We have addressed your comments in the revision 12 (https://datatracker.ietf.org/doc/html/draft-ietf-6man-spring-srv6-oam-12)
> Please also see details in-lined with [ZA] 
>  
> Thanks
>  
> Regards … Zafar 
>  
>  
> From: John Scudder via Datatracker [email-masked]
> Reply-To:  John Scudder <[email-masked]>
> Date: Wed, 02 Jun 2021 18:51:01 -0700
> To: The IESG <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> Subject: John Scudder's Discuss on draft-ietf-6man-spring-srv6-oam-11: (with DISCUSS and COMMENT)
>  
> John Scudder has entered the following ballot position for
> draft-ietf-6man-spring-srv6-oam-11: 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 DISCUSS and COMMENT positions.
>  
>  
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-6man-spring-srv6-oam/
>  
>  
>  
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>  
> I can't get past the feeling this document is really two different documents
> mashed together. One is a Standards Track, 6man document, that defines the
> O-flag. All the meat of that document is in §2.1 and §2.2, it would make a
> nice, compact, readable 3 or 4 page RFC (maybe a little more once all the
> boilerplate was in). The other is an Informational, SPRING document, that talks
> about use cases at some length. It seems both cruel and counterproductive to
> force SRv6 implementors who are implementing the O-flag to read through the
> entire balance of the document just to be sure they haven't missed something
> important. Remember these documents will live a long time, and it seems
> irresponsible to clutter the essential document set with inessential use cases.
>  
> My suggestion is to split the document as outlined above.
>  
> [ZA] Please note one of your comment requires a bit or restructuring of the document. To avoid large diffs with no substantial change, we did not make that change. If you like, we can restructure the document to address the above mentioned comment. Please advise!
>  
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>  
> Thanks to Stig Venaas for the Routing Directorate review.
>  
> I support Roman's discuss position.
>  
> 1. The Security Directorate review
> (https://mailarchive.ietf.org/arch/msg/last-call/alEuF06kwZosmLsX5FkiBVwtG4k/)
> raises a concern about privacy that hasn't been responded to, either in email
> or in the draft. The review says:
>  
>    ```
>       This draft defines a flag in the Segment Routing Header that when
>    set will result a copy of the packet being made and forwarded for
>    "telemetry data collection and export." That has tremendous security
>    and privacy implications that are not mentioned at all in the Security
>    Considerations. The Security Considerations just say that there's
>    nothing here beyond those described in <list of other RFCs>. I don't
>    think that's the case.
>  
>       Maybe I'm completely missing something but this sounds to me like
>    it enables what we used to call "service spy mode" on a router-- take
>    a flow and fork a copy off to someone else. I think there needs to be
>    a lot more discussion of the implications of this.
>    ```
>  
>    While the revision of the Security Considerations section may be sufficient
>    to address the "tremendous security... implications" the reviewer raises, it
>    does nothing to address the privacy question. The reviewer has raised a
>    serious question and deserves a serious reply to it.
>  
> [ZA] Re: the privacy consideration, we have added section on privacy consideration with the above mentioned text suggested by Roman Danyliw. We have also enhanced the security section with text suggested by Benjamin Kaduk. We hope these changes addresses your concerns. 
>  
> 2. The examples introduced in §1.3 and used throughout use the problematic
> convention of distinguishing unspecified portions of the IPv6 addresses with
> capital letters (only), as in 2001:db8::A:k::/128 (which also has an extra ::
> in it, by the way). 
>  
> [ZA] Extra :: has been fix – Thanks! 
>  
> It seems self-evidently a bad idea to use valid hexadecimal
> characters for this purpose. Please, where you don't intend to provide a
> literal hex digit, use a value not in the set a-f,A-F. The cited example could
> be rewritten as 2001:db8:X:k::/128, for example.
>  
> [ZA] Thanks for the suggestion. We have modified such that we no longer user value not in the set a-f,A-F in any of the addresses.  
>  
>    Alternately, since these are examples, shown in an example topology, it's
>    not clear to me why you couldn't simply write them out fully in real hex.
>  
> 3. You use RFC 2119 terminology incorrectly many places in the document. Recall
> that RFC 2119 defines SHOULD as:
>  
>    ```
>    3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>       may exist valid reasons in particular circumstances to ignore a
>       particular item, but the full implications must be understood and
>       carefully weighed before choosing a different course.
>    ```
>  
>    I generally use the rule of thumb that a SHOULD is almost a MUST. Here are
>    the places you've used SHOULD:
>  
>    ```
>          Ref1: An implementation SHOULD copy and record the timestamp as
>          soon as possible during packet processing. Timestamp or any other
>          metadata is not
>          carried in the packet forwarded to the next hop.
>    ```
>  
>    Can you suggest a "particular circumstance" in which it would be OK for an
>    implementor to NOT copy and record the timestamp "as soon as possible"? It
>    seems as though "as soon as possible" is already a near-infinite amount of
>    rope to allow the implementor to do anything they want, do you really need
>    to soften it further with SHOULD? I would say this should be MUST, or give
>    it up and make it "should" in lower-case.
>  
> [ZA] We have modified as per your suggestion:
>  
> Old Text> Ref1: An implementation SHOULD copy and record the timestamp as soon as possible during packet processing.
>  
> New Text> Ref1: To provide an accurate timestamp, an implementation should copy and record the timestamp as soon as possible during packet processing.
>  
>    ```
>       If the telemetry data from the ultimate segment in the segment-list
>       is required, a penultimate segment SHOULD NOT be a Penultimate
>       Segment Pop (PSP) SID.  When the penultimate segment is a PSP SID,
>       the SRH will be removed and the O-flag will not be processed at the
>       ultimate segment.
>    ```
>  
>    Since you are stating a law of physics here (well, figuratively) the SHOULD
>    NOT seems especially inapt. If I've understand the document correctly, if
>    the penultimate SID is a PSP SID then this scenario just won't work. So
>    that's not SHOULD NOT, it's either MUST NOT or more appropriately, "must
>    not" or "can't".
>  
> [ZA] We have modified as per your suggestion:
>  
> Old Text>    If the telemetry data from the ultimate segment in the segment-list
>    is required, a penultimate segment SHOULD NOT be a Penultimate
>    Segment Pop (PSP) SID.  When the penultimate segment is a PSP SID,
>    the SRH will be removed and the O-flag will not be processed at the
>    ultimate segment.
>  
> New Text> If the penultimate segment of a segment-list is a Penultimate Segment
>    Pop (PSP) SID, telemetry data from the ultimate segment cannot be
>    requested.  This is because, when the penultimate segment is a PSP
>    SID, the SRH is removed at the penultimate segment and the O-flag is
>    not processed at the ultimate segment.
>  
>  
>    ```
>       The processing node SHOULD rate-limit the number of packets punted to
>       the OAM process to a configurable rate.  This is to avoid hitting any
>       performance impact on the OAM and the telemetry collection processes.
>       Failure in implementing the rate limit can lead to a denial-of-
>       service attack, as detailed in Section 5.
>    ```
>  
>    This is a semi-legitimate SHOULD -- except, what is the "particular
>    circumstance" in which it would be OK for an implementor to NOT rate-limit?
>    Either state it (or at least provide some hints) or make this a MUST. (I
>    note the Routing Directorate reviewer also asked about this and received no
>    answer.)
>  
> [ZA] We have modified as per your suggestion and changed it to a MUST. 
>  
>    ```
>       The OAM process is expected to be located on the routing node
>       processing the packet.  Although the specification of the OAM process
>       or the external controller operations are beyond the scope of this
>       document, the OAM process SHOULD NOT be topologically distant from
>       the routing node, as this is likely to create significant security
>       and congestion issues.
>    ```
>  
>    I have no problem with this one :-o.
>  
>    ```
>                                           To exercise the behavior of a
>       target SID, the OAM operation SHOULD construct the probe in a manner
>       similar to a data packet that exercises the SID behavior, i.e. to
>       include that SID as a transit SID in either an SRH or IPv6 DA of an
>       outer IPv6 header or as appropriate based on the definition of the
>       SID behavior.
>    ```
>  
>    Again, is there a "particular circumstance" in which the OAM operation can
>    "exercise the behavior of a target SID" without doing this? If not, it's a
>    MUST or (probably better) a "should".
>  
> [ZA] We have modified as per your suggestion of the use of “should” 
>  
> 4. In Section 2.1.1:
>  
>    ```
>       The OAM process MUST NOT process the copy of the packet or respond to
>       any upper-layer header (like ICMP, UDP, etc.) payload to prevent
>       multiple evaluations of the datagram.
>    ```
>  
>    "Process" is a very general term, taken literally this means the OAM process
>    must not do anything at all with the copy it's given. Please be more
>    specific about what you mean. I'd offer text if I had a good guess as to
>    your intent, but I don't.
>  
> [ZA] This is to cover cases like when someone sends e.g., a Ping packet with the O-flag set. Now, please consider the processing at the egress node for the ping. The node will send a copy to the OAM process for telemetry purposes as it has the O-flag set. Another copy is also punted for the upper layer processing of the ping packet. If an implementation processes the upper-layer header on the copy of the packet sent for telemetry purposes (O-flag triggered copy), it may end up sending multiple eco responses to the ping initiator. The above text is to avoid such conditions.   .   
>  
>  
> 5. General comment, "classic IPv6". I find the recurrent use of the term
> "classic IPv6" along with "classic ping", "classic traceroute", etc, somehow
> jarring. We aren't marketing soft drinks! In most places you've used "classic"
> you could either provide no adjective at all (as with ping and traceroute) or
> replace with "SRv6-incapable". In some cases, the dichotomy isn't even needed,
> as in
>  
> [ZA] Agreed! Ben has a similar comment. We have made the following changes to address your and Ben’s comments: 
> ·         All classic nodes has been renamed as non-SRv6 capable nodes 
> ·         Classic ping section has been renamed as Pinging an IPv6 Address via a Segment-list
> ·         Classic traceoute section has been renamed as raceroute to an IPv6 Address via a Segment-list
>  
>    ```
>       The existing mechanism to perform the reachability checks, along the  
>       shortest path, continues to work without any modification.  The  
>       initiator may be an SRv6 node or a classic IPv6 node.  Similarly, the  
>       egress or transit may be an SRv6-capable node or a classic IPv6 node.
>    ```
>  
>    The last sentence could easily be rewritten something like  “Any IPv6 node
>    can initiate, transit, and egress a ping packet.” Similarly,
>  
> [ZA] Modified using the text suggested by you; Thanks!  
>  
>    ```
>       Similarly, the egress node (IPv6 classic or SRv6-capable) does not
>    ```
>  
>    could simply omit the parenthetical.
>  
> [ZA] Omitted!   
>  
> 6. Nit:
>  
>    ```
>       o  Node N1 initiates a traceroute probe packet with a monotonically     
>       increasing value of hop count and SRH as follows (2001:db8:A:1::,
>    ```
>  
>    "Monotonic" doesn't mean "increasing by 1 each time", which is what you mean
>    here. There are an infinite number of valid monotonic progressions that
>    wouldn't work for traceroute.
>  
> [ZA] Thanks for the catch. Removed monotonically increasing and added explicit text to indicate "increasing by 1 each time"
>  
> 7. Please define "USP" before use. You should probably just put "USP" and "PSP"
> in §1.2.
>  
> [ZA] Added both PSP and USP in the section 1.2 
>  
> 8. Nit:
>  
>    ```
>       In the reference topology in Figure 1, N100 uses an IGP protocol like  
>       OSPF or ISIS to get the topology view within the IGP domain.  N100
>    ```
>  
>    That should be "IS-IS" (with hyphen).
>  
> [ZA] Fixed
>  
> 9. In your Security Considerations you say
>  
>    ```
>       This document does not define any new protocol extensions and relies   on
>       existing procedures defined for ICMPv6.
>    ```
>  
>    Surely the O-flag, which you define, is a protocol extension.
>  
> [ZA] Yes, fixed it in the diffs

---

From: "(zali)" <[email-masked]>
Date: Fri, 14 Jan 2022 19:41:35 +0000

Hi John 

Many thanks for your follow-up and the excellent suggestion 

Let us modify and update the document, accordingly. 
In the new revision, we will also address the remaining nit (thanks for spotting it!) 

Thanks
 
Regards … Zafar 

On 1/13/22, 2:13 PM, "John Scudder" <[email-masked]> wrote:

    Hi Zafar.

    Regards,

    —John

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Mon, 24 Jan 2022 06:39:53 +0000

Hi John, 

We have posted rev-13 to address your comments (https://www.ietf.org/archive/id/draft-ietf-6man-spring-srv6-oam-13.txt) 

Summary of the diffs: 
- Diffs are editorial in nature
- Section 3 has been moved to Appendix A (as per your suggestion) 
- The revision also addresses the nits picked by you 

Please review and advise of any additional comments 

Thanks

Regards … Zafar 

On 1/14/22, 2:41 PM, "(zali)" <[email-masked]> wrote:

    Hi John 

    Thanks

    Regards … Zafar 

        Hi Zafar.

        Regards,

        —John