Re: John Scudder's Discuss on draft-ietf-6man-ipv6-alt-mark-14: (with DISCUSS and COMMENT)

[Bob Hinden <[e-mail]>]

John,

One comment below.

Bob


> On Jun 25, 2022, at 11:17 AM, John Scudder via Datatracker <[e-mail]> wrote:
> 
> John Scudder has entered the following ballot position for
> draft-ietf-6man-ipv6-alt-mark-14: 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/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-alt-mark/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> There are a few points I'd like to DISCUSS before moving this forward. The
> first should be easy to address:
> 
> 1. The number of authors (6) exceeds the maximum recommended by the RFC Editor
> (5), see RFC 7322 §4.1.1. Has this exception already been cleared with the AD?
> I see no mention of it in the shepherd writeup.

When I look at draft-ietf-6man-ipv6-alt-mark-14, I see five authors, they are:

G. Fioccola
T. Zhou
M. Cociglio
F. Qin
R. Pang

Bob


> 
> (Speaking of the shepherd writeup, and this is a comment for the shepherd and
> not the authors and is only an aside, not something that needs to be addressed
> in the DISCUSS, the writeup answer to question 1 is incomplete.)
> 
> The second is substantive rather than administrative, and may require more
> discussion:
> 
> 2. From what I understand of the rules about IPv6 extension header insertion
> (viz, only end nodes can do it), plus the assumptions stated in §2.1.1 about
> the extent of the "controlled domain", it would seem a natural consequence
> that ipv6-alt-mark is only applicable to networks where user traffic enters and
> exits a tunnel at the perimeter of the "controlled domain". I don't see this
> stated plainly anywhere in the document. If I'm correct this seems like an
> important characteristic to spell out. If I'm incorrect, I'd appreciate a
> discussion of where I went wrong.
> 
> I touch on various aspects of this overall point in some of my comments as well.
> 
> Finally, although I haven't placed any of the further comments in the DISCUSS
> section, I note that some of them are fairly fundamental so I would appreciate
> a thorough reply to the comments as well.
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 3. In §2.1.1 we have,
> 
>      the CPE (Customer Premises Equipment) is most likely to be the
>      starting or ending node since it connects the user's premises with
>      the service provider's network and therefore belongs to the
>      operator's controlled domain.  Typically the CPE encapsulates a
>      received packet in an outer IPv6 header which contains the
>      Alternate Marking data.  The CPE can also be able to filter and
>      drop packets from outside of the domain with inconsistent fields
>      to make effective the relevant security rules at the domain
>      boundaries, for example a simple security check can be to insert
>      the Alternate Marking data if and only if the destination is
>      within the controlled domain.
> 
> A remark -- I was surprised to see that the CPE is considered by the authors to
> be within the operator's security perimeter. Even if the operator manages the
> CPE (not a given), the CPE isn't physically secure, so I would assume it can't
> be considered to be as trustworthy as equipment kept on the operator's premise.
> 
> And, a question -- since in this paragraph you suggest that the controlled
> domain perimeter terminates prior to the user equipment, I read your final
> clause ("...destination is within the controlled domain") to mean that Alt-Mark
> wouldn't be usable for any traffic destined for user equipment. Thus the
> applicability would be limited to network management traffic, or overlay
> traffic that will be decapsulated somewhere within the operator network
> (perhaps at a CPE collocated with the user equipment which is the true
> destination). Is that accurate? If not, what am I missing?
> 
> I guess it's overlay traffic, since as you also point out, only the source node
> is allowed to insert the Option Header -- and for the CPE to be the source
> node, it has to be doing an encapsulation operation. Right?
> 
> (If the user equipment could be the destination, then the "simple security
> check" might not be so simple, depending on whether the user premise addressing
> comes from provider space or the user's own space.)
> 
> 4. You mention in §4 and elsewhere that the Destination Option version of the
> Alt-Mark can be processed by each node in the route list if there's a Routing
> Header present:
> 
>   o  Destination Option preceding a Routing Header => every destination
>      node in the route list.
> 
> Suppose some flavor of segment list compression is in use, such as the
> draft-ietf-spring-srv6-srh-compression NEXT-C-SID "flavor". In some cases (when
> the SID list is short enough and the compression tight enough) can't you have a
> packet that contains a SID list that's expressed entirely in what conventional
> IPv6 would call the "destination address", and no Routing Header is present?
> 
> What would the expected processing of the Alt-Mark Destination Option be in
> that case?
> 
> 5. In §2 you have
> 
>                                                 Furthermore, since the
>   Flow Label is pseudo-random, there is always a finite probability of
>   collision.  Those reasons make the definition of the FlowMonID
>   necessary for IPv6.
> 
> This objection to the pseudo-randomness of the flow label seemed OK, until I
> came to the definition of FlowMonID, which you define as... pseudo-random, and
> you later talk about its possibility of collision. Maybe you should remove the
> "furthermore" sentence, since apparently you don't have any objection to
> collisions after all?
> 
> (I return to the question of the FlowMonID later on in this review.)
> 
> 6. In §4 you have
> 
>   The Hop-by-Hop Option defined in this document is designed to take
>   advantage of the property of how Hop-by-Hop options are processed.
>   Nodes that do not support this Option SHOULD ignore them.
> 
> This doesn't seem to be written quite right. If you're just stating an
> expectation, based on the requirements from RFC 8200, then you're not
> introducing a new requirement, and you shouldn't have the RFC 2119 keyword
> there. It's also not obvious what the referent of "them" is. Do you perhaps
> mean something like this?
> 
>   The Hop-by-Hop Option defined in this document is designed to take
>   advantage of the property of how Hop-by-Hop options are processed.
>   Nodes that do not support this Option would be expected to ignore
>   it if encountered, according to the procedures of [RFC8200].
> 
> In general the paragraph that includes this sentence is repetitive, so you
> could also just remove the sentence and do a little re-wording -- but at least
> a rewrite to remove the SHOULD is necessary.
> 
> 7. In §5.1 you say,
> 
>                                                                where B
>   is the fixed time duration of the batch, which refers to the original
>   marking interval at the source node considering that this interval
>   could fluctuate along the path.
> 
> How can the interval fluctuate, considering that you've taken pains to point
> out that only the source node is able to mark the packets?
> 
> Perhaps you mean that as the packets that make up the batch traverse the
> network, their spacing would be expected to jitter based on network conditions,
> and therefore at any point in the network other than the source, the observed
> time duration might be different. If you think that is really important to
> state, I think you need to write it out in more detail, although to me it
> doesn't seem to be of the essence, so I would suggest just removing
> "considering that this interval could fluctuate along the path" -- you've
> already made it clear by saying it's the interval *at the source node*.
> 
> 8. I'm curious why you require that the FlowMonID is set pseudo-randomly. (By
> the way I assume a true random value would also be acceptable!) Assuming the
> implementation follows this:
> 
>                                                          In particular,
>   it is RECOMMENDED to consider the 3-tuple FlowMonID, source and
>   destination addresses:
> 
> Then why wouldn't it be superior for the source node to produce the FlowMonID
> by using a counter that it increments by one for each subsequent flow? The
> source node could keep such a counter globally, or per destination, depending
> on expectations of number of flows. I suppose you might be trying to keep the
> process stateless, except that you've already given up on statelessness by
> allowing for a central controller to assign FlowMonIDs.
> 
> Also it's surprising to me that it's considered reasonable to involve a central
> controller in choosing a FlowMonID per flow. It seems intuitively obvious that
> this would be unscalable and/or introduce unacceptable latency unless there are
> notably few flows in the network, and/or the flows are very long-lived. (I
> guess this could be the case if a "flow" is all the packets exchanged by a
> given ingress and egress pair of CE routers, but if that's an anticipated case
> it's not explained in the document.)
> 
> 9. I don't really understand §5.4 and would rather not take the time to read
> draft-ietf-ippm-rfc8889bis in detail to get the necessary background. I *think*
> when this section talks about clusters, these are a measurement strategy and
> there's no marking that takes place at a cluster border -- correct?
> 
> Also, in this paragraph,
> 
>   The Cluster is the smallest identifiable subnetwork of the entire
>   Network graph that still satisfies the condition that the number of
>   packets that goes in is the same that goes out.  With network
>   clustering, it is possible to use the partition of the network into
>   clusters at different levels in order to perform the needed degree of
>   detail.  So, for Multipoint Alternate Marking, FlowMonID can identify
>   in general a multipoint-to-multipoint flow and not only a point-to-
>   point flow.
> 
> The final sentence starts with "so," which implies that the final sentence
> causally follows from the previous sentences. While the statement may well be
> true as far as I know, the previous sentences aren't enough to motivate it. I
> think dropping the "so" would be enough to fix this, and then the curious
> reader could go review draft-ietf-ippm-rfc8889bis carefully to understand the
> reasons.
> 
> A second question related to this paragraph, if the Cluster is the "*smallest*
> identifiable subnetwork", etc, doesn't that mean a Cluster is always an
> individual router? Might you actually mean the *largest* identifiable
> subnetwork that satisfies the property?
> 
> 10. In §6 you say,
> 
>                                   Alternate Marking implies
>   modifications on the fly to an Option Header of IPv6 packets by the
>   source node
> 
> I am surprised by this. My impression (elaborated in some of my earlier
> questions) was that Option Headers would only be inserted by the packet's
> source, per the requirements of RFC 8200. You also take pains to say that (§2),
> 
>                The intermediate nodes and destination node MUST only
>      read the marking values of the option without modifying the Option
>      Header.
> 
> What, then, are these "modifications on the fly"?
> 
> 11. Later in §6,
> 
>                                                                 As
>   already discussed in Section 4, it is RECOMMENDED that the AltMark
>   Option does not affect the throughput and therefore the user
>   experience.
> 
> Placing requirements on router performance characteristics seems like
> overreach, to say the least -- and indeed, Section 4 doesn't do this, it takes
> the more sensible approach of explaining why the chosen design is expected to
> be implementable without adversely affecting performance. Perhaps reword
> something like,
> 
>   As is discussed in Section 4, the design of the AltMark Option has
>   been chosen with throughput in mind, such that it can be implemented
>   without affecting the user experience.
> 
> 12. Again in §6,
> 
>           In this case, nodes outside the domain MUST simply ignore
>   packets with AltMark Option since they are not configured to handle
>   it and should not process it.
> 
> I don't think you can make that statement with confidence -- what if domain A
> adjoins a different domain B which also uses AltMark within its own boundaries?
> In such a case, domain B would indeed be configured to handle it.
> 
> In such a case you would need a double-fault in containment to have a problem,
> though -- domain A would have to allow outbound leakage, and domain B would
> have to allow inbound leakage. But the statement as you've written it seems
> wrong.
> 
> In addition to the above, I don't see how you can impose requirements on nodes
> outside the domain (your use of the keyword "MUST"). After all, the nodes
> outside the domain might not implement ipv6-alt-mark at all. I think the
> keyword "MUST" is out of place here.
> 
> NITS:
> 
> 13. In §4,
> 
>                                                           A new type of
>   Routing Header, referred as Segment Routing Header (SRH), has been
>   defined in [RFC8754] for SRv6.
> 
> It isn't really so new, RFC 8754 is more than two years old now. In general I
> suggest reviewing the use of "new" when publishing any RFC, and considering
> whether it will stand the test of time -- when a reader considers your document
> in ten years, will "new" still make sense?
> 
> 14. In §5.1,
> 
>                                    In this way each marked packet can
>   be assigned to the right batch by each node.  Usually the counters
>   can be taken in the middle of the batch period to be sure to take
>   still counters.
> 
> When you say "still counters" do you mean "still" in the sense of "unmoving,
> quiescent"? I suggest "quiescent" would be less ambiguous in that case, and
> maybe "read" instead of "take" -- so "read quiescent counters".
> 
> 15. In §6,
> 
>   so the only effect is the increased MTU
> 
> It isn't the MTU that's increased, it's the packet size.
> 
> 16. In §6,
> 
>   The flow identifier (FlowMonID) composes the AltMark Option together
>   with the two marking bits (L and D).
> 
> No it doesn't, taken in this context the most obvious reading of "composes" is
> as a synonym for "concatenates", and it doesn't do that. Probably what you mean
> is this?
> 
>   The flow identifier (FlowMonID), together with the two marking bits
>   (L and D), comprises the AltMark Option.
> 
> 17. And immediately following, still in §6,
> 
>                                         As explained in Section 5.3,
>   there is a chance of collision if the FlowMonID is set pseudo
>   randomly and a solution exists.
> 
> That seems wrong. I think you've spliced incorrectly with that final "and"?
> Maybe you're saying that there's a chance of collision, but that there is a
> mitigation ("a solution") available for this problem?
> 
> 18. Again in §6,
> 
>   Additionally, it is to be noted that the AltMark Option is carried by
>   the Options Header and it may have some impact on the packet sizes
> 
> "Will have", not "may have".
> 
> 
>