[prev in list] [next in list] [prev in thread] [next in thread]
List: ipng
Subject: Re: John Scudder's Discuss on draft-ietf-6man-spring-srv6-oam-11: (with DISCUSS and COMMENT)
From: "Zafar Ali \(zali\)" <zali=40cisco.com () dmarc ! ietf ! org>
Date: 2022-01-24 6:39:53
Message-ID: 32A4E740-A17A-4852-A512-BEB4E536B442 () cisco ! com
[Download RAW message or body]
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)" <zali@cisco.com> wrote:
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" <jgs@juniper.net> wrote:
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) <zali@cisco.com> 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 noreply@ietf.org
> Reply-To: John Scudder <jgs@juniper.net>
> Date: Wed, 02 Jun 2021 18:51:01 -0700
> To: The IESG <iesg@ietf.org>
> Cc: "draft-ietf-6man-spring-srv6-oam@ietf.org" \
<draft-ietf-6man-spring-srv6-oam@ietf.org>, "6man-chairs@ietf.org" \
<6man-chairs@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>, "ot@cisco.com" \
<ot@cisco.com>, "ot@cisco.com" <ot@cisco.com>
> 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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic