IPv6 Application of the Alternate-Marking Method
draft-ietf-6man-ipv6-alt-mark-17
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-01-26
|
17 | Gunter Van de Velde | Request closed, assignment withdrawn: Victor Kuarsingh Last Call OPSDIR review |
2024-01-26
|
17 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue |
2022-12-14
|
17 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2022-12-12
|
17 | (System) | RFC Editor state changed to AUTH48 |
2022-10-18
|
17 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2022-09-30
|
17 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2022-09-30
|
17 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2022-09-30
|
17 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2022-09-29
|
17 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2022-09-27
|
17 | (System) | RFC Editor state changed to EDIT |
2022-09-27
|
17 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2022-09-27
|
17 | (System) | Announcement was received by RFC Editor |
2022-09-27
|
17 | (System) | IANA Action state changed to In Progress |
2022-09-27
|
17 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2022-09-27
|
17 | Cindy Morgan | IESG has approved the document |
2022-09-27
|
17 | Cindy Morgan | Closed "Approve" ballot |
2022-09-27
|
17 | Cindy Morgan | Ballot approval text was generated |
2022-09-27
|
17 | (System) | Removed all action holders (IESG state changed) |
2022-09-27
|
17 | Erik Kline | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2022-09-27
|
17 | Giuseppe Fioccola | New version available: draft-ietf-6man-ipv6-alt-mark-17.txt |
2022-09-27
|
17 | (System) | New version approved |
2022-09-27
|
17 | (System) | Request for posting confirmation emailed to previous authors: 6man-chairs@ietf.org, Fengwei Qin , Giuseppe Fioccola , Mauro Cociglio , Ran Pang , Tianran Zhou |
2022-09-27
|
17 | Giuseppe Fioccola | Uploaded new revision |
2022-09-12
|
16 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2022-07-13
|
16 | Francesca Palombini | [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini |
2022-07-12
|
16 | John Scudder | [Ballot comment] Hi Giuseppe, Thanks for the updates in version 16. I've cleared my DISCUSS. I do have some new comments which I'm providing below. … [Ballot comment] Hi Giuseppe, Thanks for the updates in version 16. I've cleared my DISCUSS. I do have some new comments which I'm providing below. 1. In §1, Besides, [RFC8799] also discusses the trend towards network behaviors that can be applied only within limited domains. I suggest slightly re-wording like [RFC8799] provides further discussion of network behaviors that can be applied only within limited domains. Apart from just stylistic preference, this change reduces the risk that the reader may think RFC 8799 is being pointed to as a source of authority rather than supplemental information. 2. In §2.1.1, the CPE (Customer Premises Equipment) and the PE (Provider Edge) router are most likely to be the starting or ending node since Shouldn't this be CPE *or* PE? they can border a controlled domain. For instance, the CPE, which "They can border" doesn't seem quite right since it implies the CPE or PE would be on the exterior of, but adjacent to, the domain. Do you mean, "they can be border routers of the controlled domain"? 3. In §4, If segment list compression is in use, as described in [I-D.ietf-spring-srv6-srh-compression], Destination Options or Hop-by-Hop Options can always be applicable. Please forgive me but the meaning of this sentence isn't clear to me. When I work through what I *think* you're trying to say, it's something like "when compression is in use there might not be a RH and in that case DOs if present, are processed at every SR node along the compressed segment list". Is that right? In looking at draft-ietf-spring-srv6-srh-compression-01 and other related specs, I actually can't figure out WHAT is supposed to happen with DOs in the NEXT-C-SID case :-(. That leaves us with a few options I guess: - Educate me to understand why draft-ietf-spring-srv6-srh-compression-01 is actually not ambiguous in this regard (I am already working on this but have not reached a happy conclusion). - Correct draft-ietf-spring-srv6-srh-compression-01 to be unambiguous, and update the text in your draft to match (but then this gives you a dependency on that work). - Find a way to remove the dependency on SRv6 from your draft. To me, the final option seems like the most attractive since it introduces no dependencies. A sketch of text that might do the job: IPv6 [RFC8200] provides both Hop-by-Hop Options and Destination Options headers, furthermore depending on how the Destination Options are situated in the header chain (before, or after, the Routing Header if any), they may be processed by either intermediate routers specified in the Routing Header, or the destination node. Using these tools, it is possible to control on which nodes measurement occurs: o Destination Option not preceding a Routing Header => measurement only by node in Destination Address. o Hop-by-Hop Option => every router on the path with feature enabled. o Destination Option preceding a Routing Header => every destination node in the route list. Then leave it to the SRv6 document set to specify whatever's necessary with respect to DO processing, and if any variance with regard to placement before/after RH is required, it's up to the SRv6 document set to specify it. 4. In §5.3, This is OK, The FlowMonID allocation procedure can be stateful or stateless. In case of a stateful approach, it is required that each source node stores and keeps track of the FlowMonID historic information in order to assign unique values within the domain. This may imply a complex procedure and it is considered out of scope for this document. But, isn't most of the complexity required in this case for the purposes of tracking and retrieving what ID you associated with which flow? And therefore, that complexity would also be required in the case of a centralized controller, mentioned just a few paragraphs down in bullet 2? |
2022-07-12
|
16 | John Scudder | Ballot comment text updated for John Scudder |
2022-07-12
|
16 | John Scudder | [Ballot comment] Hi Giuseppe, Thanks for the updates in version 16. I've cleared my DISCUSS. I do have some new comments which I'm providing below. … [Ballot comment] Hi Giuseppe, Thanks for the updates in version 16. I've cleared my DISCUSS. I do have some new comments which I'm providing below. 1. In §1, Besides, [RFC8799] also discusses the trend towards network behaviors that can be applied only within limited domains. I suggest slightly re-wording like [RFC8799] provides further discussion of network behaviors that can be applied only within limited domains. Apart from just stylistic preference, this change reduces the risk that the reader may think RFC 8799 is being pointed to as a source of authority rather than supplemental information. 2. In §2.1.1, the CPE (Customer Premises Equipment) and the PE (Provider Edge) router are most likely to be the starting or ending node since Shouldn't this be CPE *or* PE? they can border a controlled domain. For instance, the CPE, which "They can border" doesn't seem quite right since it implies the CPE or PE would be on the exterior of, but adjacent to, the domain. Do you mean, "they can be border routers of the controlled domain"? 3. In §4, If segment list compression is in use, as described in [I-D.ietf-spring-srv6-srh-compression], Destination Options or Hop-by-Hop Options can always be applicable. Please forgive me but the meaning of this sentence isn't clear to me. When I work through what I *think* you're trying to say, it's something like "when compression is in use there might not be a RH and in that case DOs if present, are processed at every SR node along the compressed segment list". Is that right? In looking at draft-ietf-spring-srv6-srh-compression-01 and other related specs, I actually can't figure out WHAT is supposed to happen with DOs in the NEXT-C-SID case :-(. That leaves us with a few options I guess: - Educate me to understand why draft-ietf-spring-srv6-srh-compression-01 is actually not ambiguous in this regard (I am already working on this but have not reached a happy conclusion). - Correct draft-ietf-spring-srv6-srh-compression-01 to be unambiguous, and update the text in your draft to match (but then this gives you a dependency on that work). - Find a way to remove the dependency on SRv6 from your draft. To me, the final option seems like the most attractive since it introduces no dependencies. A sketch of text that might do the job: IPv6 [RFC8200] provides both Hop-by-Hop Options and Destination Options headers, furthermore depending on how the Destination Options are situated in the header chain (before, or after, the Routing Header if any), they may be processed by either intermediate routers specified in the Routing Header, or the destination node. Using these tools, it is possible to control on which nodes measurement occurs: o Destination Option not preceding a Routing Header => measurement only by node in Destination Address. o Hop-by-Hop Option => every router on the path with feature enabled. o Destination Option preceding a Routing Header => every destination node in the route list. Then leave it to the SRv6 document set to specify whatever's necessary with respect to DO processing, and if any variance with regard to placement before/after RH is required, it's up to the SRv6 document set to specify it. 4. In §5.3, This is OK, The FlowMonID allocation procedure can be stateful or stateless. In case of a stateful approach, it is required that each source node stores and keeps track of the FlowMonID historic information in order to assign unique values within the domain. This may imply a complex procedure and it is considered out of scope for this document. But, isn't most of the complexity required in this case for the purposes of tracking and retrieving what ID you associated with which flow? And that therefore, that complexity would also be required in the case of a centralized controller, mentioned just a few paragraphs down in bullet 2? |
2022-07-12
|
16 | John Scudder | Ballot comment text updated for John Scudder |
2022-07-12
|
16 | John Scudder | [Ballot comment] Hi Giuseppe, Thanks for the updates in version 16. I've cleared my DISCUSS. I do have some new comments which I'm providing below. … [Ballot comment] Hi Giuseppe, Thanks for the updates in version 16. I've cleared my DISCUSS. I do have some new comments which I'm providing below. 1. In §1, Besides, [RFC8799] also discusses the trend towards network behaviors that can be applied only within limited domains. I suggest slightly re-wording like [RFC8799] provides further discussion of network behaviors that can be applied only within limited domains. Apart from just stylistic preference, this change reduces the risk that the reader may think RFC 8799 is being pointed to as a source of authority rather than supplemental information. 2. In §2.1.1, the CPE (Customer Premises Equipment) and the PE (Provider Edge) router are most likely to be the starting or ending node since Shouldn't this be CPE *or* PE? they can border a controlled domain. For instance, the CPE, which "They can border" doesn't seem quite right since it implies the CPE or PE would be on the exterior of, but adjacent to, the domain. Do you mean, "they can be border routers of the controlled domain"? 3. In §4, If segment list compression is in use, as described in [I-D.ietf-spring-srv6-srh-compression], Destination Options or Hop-by-Hop Options can always be applicable. Please forgive me but the meaning of this sentence isn't clear to me. When I work through what I *think* you're trying to say, it's something like "when compression is in use there might not be a RH and in that case DOs if present, are processed at every SR node along the compressed segment list". Is that right? In looking at draft-ietf-spring-srv6-srh-compression-01 and other related specs, I actually can't figure out WHAT is supposed to happen with DOs in the NEXT-C-SID case :-(. That leaves us with a few options I guess: - Educate me to understand why draft-ietf-spring-srv6-srh-compression-01 is actually not ambiguous in this regard (I am already working on this but have not reached a happy conclusion). - Correct draft-ietf-spring-srv6-srh-compression-01 to be unambiguous, and update the text in your draft to match (but then this gives you a dependency on that work). - Find a way to remove the dependency on SRv6 from your draft. To me, the final option seems like the most attractive since it introduces no dependencies. A sketch of text that might do the job: IPv6 [RFC8200] provides both Hop-by-Hop Options and Destination Options headers, furthermore depending on how the Destination Options are situated in the header chain (before, or after, the Routing Header if any), they may be processed by either intermediate routers specified in the Routing Header, or the destination node. Using these tools, it is possible to control on which nodes measurement occurs: o Destination Option not preceding a Routing Header => measurement only by node in Destination Address. o Hop-by-Hop Option => every router on the path with feature enabled. o Destination Option preceding a Routing Header => every destination node in the route list. Then leave it to the SRv6 document set to specify whatever's necessary with respect to DO processing, and if any variance with regard to placement before/after RH is required, it's up to the SRv6 document set to specify it. 4. In §5.3, This is OK, The FlowMonID allocation procedure can be stateful or stateless. In case of a stateful approach, it is required that each source node stores and keeps track of the FlowMonID historic information in order to assign unique values within the domain. This may imply a complex procedure and it is considered out of scope for this document. But, isn't most of the complexity required in this case is for the purposes of tracking and retrieving what ID you associated with which flow? And that therefore, that complexity would also be required in the case of a centralized controller, mentioned just a few paragraphs down in bullet 2? |
2022-07-12
|
16 | John Scudder | Ballot comment text updated for John Scudder |
2022-07-12
|
16 | John Scudder | [Ballot comment] Hi Giuseppe, Thanks for the updates in version 16. I've cleared my DISCUSS. I do have some new comments which I'm providing below. … [Ballot comment] Hi Giuseppe, Thanks for the updates in version 16. I've cleared my DISCUSS. I do have some new comments which I'm providing below. 1. In §1, Besides, [RFC8799] also discusses the trend towards network behaviors that can be applied only within limited domains. I suggest slightly re-wording like [RFC8799] provides further discussion of network behaviors that can be applied only within limited domains. Apart from just stylistic preference, this change reduces the risk that the reader may think RFC 8799 is being pointed to as a source of authority rather than supplemental information. 2. In §2.1.1, the CPE (Customer Premises Equipment) and the PE (Provider Edge) router are most likely to be the starting or ending node since Shouldn't this be CPE *or* PE? they can border a controlled domain. For instance, the CPE, which "They can border" doesn't seem quite right since it implies the CPE or PE would be on the exterior of, but adjacent to, the domain. Do you mean, "they can be border routers of the controlled domain"? 3. In §4, If segment list compression is in use, as described in [I-D.ietf-spring-srv6-srh-compression], Destination Options or Hop-by-Hop Options can always be applicable. Please forgive me but the meaning of this sentence isn't clear to me. When I work through what I *think* you're trying to say, it's something like "when compression is in use there might not be a RH and in that case DOs if present, are processed at every SR node along the compressed segment list". Is that right? In looking at draft-ietf-spring-srv6-srh-compression-01 and other related specs, I actually can't figure out WHAT is supposed to happen with DOs in the NEXT-C-SID case :-(. That leaves us with a few options I guess: - Educate me to understand why draft-ietf-spring-srv6-srh-compression-01 is actually not ambiguous in this regard (I am already working on this but have not reached a happy conclusion). - Correct draft-ietf-spring-srv6-srh-compression-01 to be unambiguous, and update the text in your draft to match (but then this gives you a dependency on that work). - Find a way to remove the dependency on SRv6 from your draft. To me, the final option seems like the most attractive since it introduces no dependencies. A sketch of text that might do the job: IPv6 [RFC8200] provides both Hop-by-Hop Options and Destination Options headers, furthermore depending on how the Destination Options are situated in the header chain (before, or after, the Routing Header if any), they may be processed by either intermediate routers specified in the Routing Header, or the destination node. Using these tools, it is possible to control on which nodes measurement occurs: o Destination Option not preceding a Routing Header => measurement only by node in Destination Address. o Hop-by-Hop Option => every router on the path with feature enabled. o Destination Option preceding a Routing Header => every destination node in the route list. Then leave it to the SRv6 document set to specify whatever's necessary with respect to DO processing, and if any variance with regard to placement before/after RH is required, it's up to the SRv6 document set to specify it. 4. In §5.3, This is OK, The FlowMonID allocation procedure can be stateful or stateless. In case of a stateful approach, it is required that each source node stores and keeps track of the FlowMonID historic information in order to assign unique values within the domain. This may imply a complex procedure and it is considered out of scope for this document. But, isn't it the case that most of the complexity required in this case is for the purposes of tracking and retrieving what ID you associated with which flow? And that therefore, that complexity would also be required in the case of a centralized controller, mentioned just a few paragraphs down in bullet 2? |
2022-07-12
|
16 | John Scudder | Ballot comment text updated for John Scudder |
2022-07-12
|
16 | John Scudder | [Ballot comment] Hi Giuseppe, Thanks for the updates in version 16. I've cleared my DISCUSS, but I do have additional comments which I'm providing below. … [Ballot comment] Hi Giuseppe, Thanks for the updates in version 16. I've cleared my DISCUSS, but I do have additional comments which I'm providing below. 1. In §1, Besides, [RFC8799] also discusses the trend towards network behaviors that can be applied only within limited domains. I suggest slightly re-wording like [RFC8799] provides further discussion of network behaviors that can be applied only within limited domains. Apart from just stylistic preference, this change reduces the risk that the reader may think RFC 8799 is being pointed to as a source of authority rather than supplemental information. 2. In §2.1.1, the CPE (Customer Premises Equipment) and the PE (Provider Edge) router are most likely to be the starting or ending node since Shouldn't this be CPE *or* PE? they can border a controlled domain. For instance, the CPE, which "They can border" doesn't seem quite right since it implies the CPE or PE would be on the exterior of, but adjacent to, the domain. Do you mean, "they can be border routers of the controlled domain"? 3. In §4, If segment list compression is in use, as described in [I-D.ietf-spring-srv6-srh-compression], Destination Options or Hop-by-Hop Options can always be applicable. Please forgive me but the meaning of this sentence isn't clear to me. When I work through what I *think* you're trying to say, it's something like "when compression is in use there might not be a RH and in that case DOs if present, are processed at every SR node along the compressed segment list". Is that right? In looking at draft-ietf-spring-srv6-srh-compression-01 and other related specs, I actually can't figure out WHAT is supposed to happen with DOs in the NEXT-C-SID case :-(. That leaves us with a few options I guess: - Educate me to understand why draft-ietf-spring-srv6-srh-compression-01 is actually not ambiguous in this regard (I am already working on this but have not reached a happy conclusion). - Correct draft-ietf-spring-srv6-srh-compression-01 to be unambiguous, and update the text in your draft to match (but then this gives you a dependency on that work). - Find a way to remove the dependency on SRv6 from your draft. To me, the final option seems like the most attractive since it introduces no dependencies. A sketch of text that might do the job: IPv6 [RFC8200] provides both Hop-by-Hop Options and Destination Options headers, furthermore depending on how the Destination Options are situated in the header chain (before, or after, the Routing Header if any), they may be processed by either intermediate routers specified in the Routing Header, or the destination node. Using these tools, it is possible to control on which nodes measurement occurs: o Destination Option not preceding a Routing Header => measurement only by node in Destination Address. o Hop-by-Hop Option => every router on the path with feature enabled. o Destination Option preceding a Routing Header => every destination node in the route list. Then leave it to the SRv6 document set to specify whatever's necessary with respect to DO processing, and if any variance with regard to placement before/after RH is required, it's up to the SRv6 document set to specify it. 4. In §5.3, This is OK, The FlowMonID allocation procedure can be stateful or stateless. In case of a stateful approach, it is required that each source node stores and keeps track of the FlowMonID historic information in order to assign unique values within the domain. This may imply a complex procedure and it is considered out of scope for this document. But, isn't it the case that most of the complexity required in this case is for the purposes of tracking and retrieving what ID you associated with which flow? And that therefore, that complexity would also be required in the case of a centralized controller, mentioned just a few paragraphs down in bullet 2? |
2022-07-12
|
16 | John Scudder | [Ballot Position Update] Position for John Scudder has been changed to No Objection from Discuss |
2022-07-01
|
16 | Giuseppe Fioccola | New version available: draft-ietf-6man-ipv6-alt-mark-16.txt |
2022-07-01
|
16 | (System) | New version approved |
2022-07-01
|
16 | (System) | Request for posting confirmation emailed to previous authors: Fengwei Qin , Giuseppe Fioccola , Mauro Cociglio , Ran Pang , Tianran Zhou |
2022-07-01
|
16 | Giuseppe Fioccola | Uploaded new revision |
2022-06-29
|
15 | Giuseppe Fioccola | New version available: draft-ietf-6man-ipv6-alt-mark-15.txt |
2022-06-29
|
15 | (System) | New version approved |
2022-06-29
|
15 | (System) | Request for posting confirmation emailed to previous authors: Fengwei Qin , Giuseppe Fioccola , Mauro Cociglio , Ran Pang , Tianran Zhou |
2022-06-29
|
15 | Giuseppe Fioccola | Uploaded new revision |
2022-06-25
|
14 | John Scudder | [Ballot comment] 3. In §2.1.1 we have, the CPE (Customer Premises Equipment) is most likely to be the starting … [Ballot 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". |
2022-06-25
|
14 | John Scudder | Ballot comment text updated for John Scudder |
2022-06-25
|
14 | John Scudder | [Ballot 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 … [Ballot 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. (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. |
2022-06-25
|
14 | John Scudder | Ballot discuss text updated for John Scudder |
2022-06-25
|
14 | John Scudder | [Ballot 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 … [Ballot 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. (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 noted that some of them are fairly fundamental so I would appreciate a thorough reply to the comments as well. |
2022-06-25
|
14 | John Scudder | Ballot discuss text updated for John Scudder |
2022-06-25
|
14 | John Scudder | [Ballot 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 … [Ballot 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. (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 noted that some of them are fairly fundamental so I would appreciate a thorough reply to the comments as well. |
2022-06-25
|
14 | John Scudder | [Ballot comment] 3. In §2.1.1 we have, the CPE (Customer Premises Equipment) is most likely to be the starting … [Ballot 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". |
2022-06-25
|
14 | John Scudder | [Ballot Position Update] New position, Discuss, has been recorded for John Scudder |
2022-05-17
|
14 | Warren Kumari | [Ballot comment] I'm changing my DISCUSS to an Abstain (a non-blocking position); the most recent version does address some of my concerns, but not all. … [Ballot comment] I'm changing my DISCUSS to an Abstain (a non-blocking position); the most recent version does address some of my concerns, but not all. I'm clearing my DISCUSS because I don't seem to have been able to adequately describe my concerns and it feels obstructionist to continue to hold it. I'd also like to apologize to the WG, authors, and Giuseppe in particular; Giuseppe has been sending me mail and (politely) chasing me to respond and let him know if his changes have addressed my concerns, and I've been sufficiently frustrated by my inability to express my concerns concisely that I've been ignoring it and not responding to him. Apologies again. |
2022-05-17
|
14 | Warren Kumari | [Ballot Position Update] Position for Warren Kumari has been changed to Abstain from Discuss |
2022-04-28
|
14 | Martin Duke | [Ballot comment] Thanks for addressing my DISCUSS. Thanks to Yoshi for the TSVART review. |
2022-04-28
|
14 | Martin Duke | [Ballot Position Update] Position for Martin Duke has been changed to No Objection from Discuss |
2022-04-28
|
14 | Giuseppe Fioccola | New version available: draft-ietf-6man-ipv6-alt-mark-14.txt |
2022-04-28
|
14 | (System) | New version approved |
2022-04-28
|
14 | (System) | Request for posting confirmation emailed to previous authors: Fengwei Qin , Giuseppe Fioccola , Mauro Cociglio , Ran Pang , Tianran Zhou |
2022-04-28
|
14 | Giuseppe Fioccola | Uploaded new revision |
2022-03-31
|
13 | Martin Duke | [Ballot discuss] Thanks for addressing most of my DISCUSS points. I would like an unambiguous statement in Section 3.1 that the FlowMonID MUST appear to … [Ballot discuss] Thanks for addressing most of my DISCUSS points. I would like an unambiguous statement in Section 3.1 that the FlowMonID MUST appear to be random. There is still language that suggests it might not be: (e.g., "The disambiguation issue is more visible when the FlowMonID is pseudorandomly generated...". If it is anything less than a MUST, there needs to be additional Security Considerations to reflect the impact of not doing so. |
2022-03-31
|
13 | Martin Duke | Ballot discuss text updated for Martin Duke |
2022-03-31
|
13 | Giuseppe Fioccola | New version available: draft-ietf-6man-ipv6-alt-mark-13.txt |
2022-03-31
|
13 | (System) | New version approved |
2022-03-31
|
13 | (System) | Request for posting confirmation emailed to previous authors: Fengwei Qin , Giuseppe Fioccola , Mauro Cociglio , Ran Pang , Tianran Zhou |
2022-03-31
|
13 | Giuseppe Fioccola | Uploaded new revision |
2022-01-10
|
12 | Roman Danyliw | [Ballot comment] Thank you to Chris Wood for the SECDIR review and to the authors for responding to it. Thank you for the document revisions … [Ballot comment] Thank you to Chris Wood for the SECDIR review and to the authors for responding to it. Thank you for the document revisions to address my DISCUSS and COMMENT feedback. |
2022-01-10
|
12 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss |
2021-11-29
|
Tina Dang | Posted related IPR disclosure Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-6man-ipv6-alt-mark | |
2021-10-26
|
12 | Lars Eggert | [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss |
2021-10-22
|
12 | Giuseppe Fioccola | New version available: draft-ietf-6man-ipv6-alt-mark-12.txt |
2021-10-22
|
12 | (System) | New version approved |
2021-10-22
|
12 | (System) | Request for posting confirmation emailed to previous authors: Fengwei Qin , Giuseppe Fioccola , Mauro Cociglio , Ran Pang , Tianran Zhou |
2021-10-22
|
12 | Giuseppe Fioccola | Uploaded new revision |
2021-10-21
|
11 | Giuseppe Fioccola | New version available: draft-ietf-6man-ipv6-alt-mark-11.txt |
2021-10-21
|
11 | (System) | New version approved |
2021-10-21
|
11 | (System) | Request for posting confirmation emailed to previous authors: Fengwei Qin , Giuseppe Fioccola , Mauro Cociglio , Ran Pang , Tianran Zhou |
2021-10-21
|
11 | Giuseppe Fioccola | Uploaded new revision |
2021-10-07
|
10 | Éric Vyncke | [Ballot comment] Giuseppe, Thank you for the -10 revision, which indeed addresses all my previous DISCUSS. Hence, I am now balloting NO OBJECTION to the … [Ballot comment] Giuseppe, Thank you for the -10 revision, which indeed addresses all my previous DISCUSS. Hence, I am now balloting NO OBJECTION to the document. Please ignore the DISCUSS points below that I kept only for documentation. Regards -éric -- everything below is for archiving purpose only -- Thank you for the work put into this document. As Brian Carpenter kindly reminded me that an Area Director may not put back a previous argument when the WG consensus was to ignore it, I am updating this ballot by moving the generic DISCUSS as a COMMENT. The other two DISCUSS points remains blocking ones but Giuseppe have already addressed them over email, I am clearing the DISCUSS position as soon as the revised I-D is posted. Special thanks to Ole Trøan for his shepherd's write-up, which contains a good summary of the WG consensus and the SW (?) implementation status. Thanks as well to Bob Halley for his INT directorate review. Please find below some blocking DISCUSS points, some non-blocking COMMENT points (but replies would be appreciated). I also agree with DISCUSS points by other ADs: - Lars's one about the size and usefulness of FlowMonID (see my very similar point) - Roman's one about the inconsistencies about limited domain (from my point of view, this should not be limited to a single domain) All in all, I strongly suggest to change the intended status of this document to 'experimental' as this document builds on experimental RFCs. I hope that this helps to improve the document, Regards, -éric == PREVIOUS DISCUSS (only for archives) == -- Section 2 -- "In the end, [I-D.fioccola-v6ops-ipv6-alt-mark] demonstrated that a new Hop-by-Hop or a new Destination Option was the best approach." The above draft has not been published and is even expired for 2 years now... so please remove the 'demonstrated' as there is no proof at all ;-) -- Section 4 -- Please remove "the destination node removes it" as there is no reason to remove it. Extension headers are usually not presented / used by upper layers anyway. -- generic -- This discussion already happened in the 6MAN WG but I still have to be convinced that hop-by-hop is a good idea at all. The fate of packets with HbH is unknown at best and, IMHO, this is a wrong use of HbH because the forwarding/processing of packets is NOT influenced at all by the AltMark option. What is required is a simple 'marking/coloring', which could be at any place in a packet (including destination option). The only benefit of HbH is its location just after the IPv6 header. After all, existing devices can measure and generate IPFIX records in hardware/fastpath by inspecting at the bare minimum the 5-tuple and many devices can also parse extension headers in the fast path (of course not processing HbH in this case). I.e., finding the marking in the Dest Option is probably much easier and doable in current hardware rather than using HbH as HbH forces a software processing. --- PREVIOUS COMMENT (for archive) --- -- Section 2.1 -- While I agree with my fellow AD about the inconsistencies of the text around 'limited domain' (and being inconsistent deserves a blocking DISCUSS), I do not agree with this section as I do not see any harm to extend this marking outside of a single domain, marked packets with this specification can traverse the whole Internet without causing any harm and not opening for any attack on the transit nodes. (See also my point about Hop-by-hop) E.g., packets from organisation A can traverse networks of organizations B, C, ..., Z to reach another site of organization A and still provide useful measurements for A without causing harm to B, C, ..., Z. Of course the survivability of those marked packets is not guaranteed. -- Section 3.1 -- Is there any reason why the FlowMonID is 20 bit long ? Exactly as the 20-bit Flow Label of the IPv6 header... See my comments for section 5.3 s/Unrecognized Types MUST be ignored on receipt./Unrecognized Types MUST be ignored on processing./ as the option should be processed not only by the destination node. -- Section 5 -- This section (in a standard track I-D) repeats many things from experimental RFCs... This is really confusing and, while I am usually not dogmatic, I support my fellow AD on this point. Moreover, repeating contents from other docs can only introduce inconsistencies among docs => suggest to remove section 5.1 and 5.2. -- Section 5.3 -- The general reasons of using a 20-bit FlowMonID appear quite weak to me with the risk of collision being very high, e.g., in a DC with thousands of VM and millions of containers there will be collisions rendering this field useless. Strongly suggest to make its use optional |
2021-10-07
|
10 | Éric Vyncke | [Ballot Position Update] Position for Éric Vyncke has been changed to No Objection from Discuss |
2021-09-21
|
10 | Luc André Burdet | Request closed, assignment withdrawn: Emmanuel Baccelli Telechat RTGDIR review |
2021-09-21
|
10 | Luc André Burdet | Closed request for Telechat review by RTGDIR with state 'Overtaken by Events': Document has been through the IESG — waiting on DISCUSS but don’t need … Closed request for Telechat review by RTGDIR with state 'Overtaken by Events': Document has been through the IESG — waiting on DISCUSS but don’t need the rtg-dir review anymore |
2021-09-17
|
10 | Haomian Zheng | Request for Telechat review by RTGDIR is assigned to Emmanuel Baccelli |
2021-09-17
|
10 | Haomian Zheng | Request for Telechat review by RTGDIR is assigned to Emmanuel Baccelli |
2021-09-14
|
10 | Giuseppe Fioccola | New version available: draft-ietf-6man-ipv6-alt-mark-10.txt |
2021-09-14
|
10 | (System) | New version approved |
2021-09-14
|
10 | (System) | Request for posting confirmation emailed to previous authors: Fengwei Qin , Giuseppe Fioccola , Mauro Cociglio , Ran Pang , Tianran Zhou |
2021-09-14
|
10 | Giuseppe Fioccola | Uploaded new revision |
2021-08-27
|
09 | (System) | Changed action holders to Erik Kline (IESG state changed) |
2021-08-27
|
09 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-08-27
|
09 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2021-08-27
|
09 | Giuseppe Fioccola | New version available: draft-ietf-6man-ipv6-alt-mark-09.txt |
2021-08-27
|
09 | (System) | New version approved |
2021-08-27
|
09 | (System) | Request for posting confirmation emailed to previous authors: Fengwei Qin , Giuseppe Fioccola , Mauro Cociglio , Ran Pang , Tianran Zhou |
2021-08-27
|
09 | Giuseppe Fioccola | Uploaded new revision |
2021-08-13
|
08 | Luc André Burdet | Assignment of request for Telechat review by RTGDIR to Tony Przygienda was withdrawn |
2021-08-13
|
08 | Luc André Burdet | Request for Telechat review by RTGDIR is assigned to Tony Przygienda |
2021-08-13
|
08 | Luc André Burdet | Request for Telechat review by RTGDIR is assigned to Tony Przygienda |
2021-08-12
|
08 | (System) | Changed action holders to Erik Kline, Mauro Cociglio, Tianran Zhou, Giuseppe Fioccola, Fengwei Qin, Ran Pang (IESG state changed) |
2021-08-12
|
08 | Amy Vezza | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2021-08-12
|
08 | Stewart Bryant | Request for Telechat review by GENART Completed: Not Ready. Reviewer: Stewart Bryant. Sent review to list. |
2021-08-12
|
08 | Murray Kucherawy | [Ballot Position Update] Position for Murray Kucherawy has been changed to No Objection from Discuss |
2021-08-12
|
08 | Éric Vyncke | [Ballot discuss] Thank you for the work put into this document. As Brian Carpenter kindly reminded me that an Area Director may not put back … [Ballot discuss] Thank you for the work put into this document. As Brian Carpenter kindly reminded me that an Area Director may not put back a previous argument when the WG consensus was to ignore it, I am updating this ballot by moving the generic DISCUSS as a COMMENT. The other two DISCUSS points remains blocking ones but Giuseppe have already addressed them over email, I am clearing the DISCUSS position as soon as the revised I-D is posted. Special thanks to Ole Trøan for his shepherd's write-up, which contains a good summary of the WG consensus and the SW (?) implementation status. Thanks as well to Bob Halley for his INT directorate review. Please find below some blocking DISCUSS points, some non-blocking COMMENT points (but replies would be appreciated). I also agree with DISCUSS points by other ADs: - Lars's one about the size and usefulness of FlowMonID (see my very similar point) - Roman's one about the inconsistencies about limited domain (from my point of view, this should not be limited to a single domain) All in all, I strongly suggest to change the intended status of this document to 'experimental' as this document builds on experimental RFCs. I hope that this helps to improve the document, Regards, -éric == DISCUSS == -- Section 2 -- "In the end, [I-D.fioccola-v6ops-ipv6-alt-mark] demonstrated that a new Hop-by-Hop or a new Destination Option was the best approach." The above draft has not been published and is even expired for 2 years now... so please remove the 'demonstrated' as there is no proof at all ;-) -- Section 4 -- Please remove "the destination node removes it" as there is no reason to remove it. Extension headers are usually not presented / used by upper layers anyway. |
2021-08-12
|
08 | Éric Vyncke | [Ballot comment] --- OLD DISCUSS ---- This discussion already happened in the 6MAN WG but I still have to be convinced that hop-by-hop is a … [Ballot comment] --- OLD DISCUSS ---- This discussion already happened in the 6MAN WG but I still have to be convinced that hop-by-hop is a good idea at all. The fate of packets with HbH is unknown at best and, IMHO, this is a wrong use of HbH because the forwarding/processing of packets is NOT influenced at all by the AltMark option. What is required is a simple 'marking/coloring', which could be at any place in a packet (including destination option). The only benefit of HbH is its location just after the IPv6 header. After all, existing devices can measure and generate IPFIX records in hardware/fastpath by inspecting at the bare minimum the 5-tuple and many devices can also parse extension headers in the fast path (of course not processing HbH in this case). I.e., finding the marking in the Dest Option is probably much easier and doable in current hardware rather than using HbH as HbH forces a software processing. --- END OF OLD DISCUSS --- -- Section 2.1 -- While I agree with my fellow AD about the inconsistencies of the text around 'limited domain' (and being inconsistent deserves a blocking DISCUSS), I do not agree with this section as I do not see any harm to extend this marking outside of a single domain, marked packets with this specification can traverse the whole Internet without causing any harm and not opening for any attack on the transit nodes. (See also my point about Hop-by-hop) E.g., packets from organisation A can traverse networks of organizations B, C, ..., Z to reach another site of organization A and still provide useful measurements for A without causing harm to B, C, ..., Z. Of course the survivability of those marked packets is not guaranteed. -- Section 3.1 -- Is there any reason why the FlowMonID is 20 bit long ? Exactly as the 20-bit Flow Label of the IPv6 header... See my comments for section 5.3 s/Unrecognized Types MUST be ignored on receipt./Unrecognized Types MUST be ignored on processing./ as the option should be processed not only by the destination node. -- Section 5 -- This section (in a standard track I-D) repeats many things from experimental RFCs... This is really confusing and, while I am usually not dogmatic, I support my fellow AD on this point. Moreover, repeating contents from other docs can only introduce inconsistencies among docs => suggest to remove section 5.1 and 5.2. -- Section 5.3 -- The general reasons of using a 20-bit FlowMonID appear quite weak to me with the risk of collision being very high, e.g., in a DC with thousands of VM and millions of containers there will be collisions rendering this field useless. Strongly suggest to make its use optional |
2021-08-12
|
08 | Éric Vyncke | Ballot comment and discuss text updated for Éric Vyncke |
2021-08-12
|
08 | Martin Vigoureux | [Ballot comment] very late review and as such not much to add to the existing ones, with which I largely agree |
2021-08-12
|
08 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2021-08-11
|
08 | Murray Kucherawy | [Ballot discuss] A procedural question about the IPR disclosures, which I expect we can clear up during the telechat in a few hours: Though there … [Ballot discuss] A procedural question about the IPR disclosures, which I expect we can clear up during the telechat in a few hours: Though there have been two IPR disclosures on this document, the shepherd writeup conspicuously claims there has been no discussion about either. For at least one of them the licensing terms indicate a fee may apply. As this is seeking Proposed Standard status, I'd like to inquire about this. In particular, Section 4 of BCP 79 says: A working group may take into consideration the results of this procedure in evaluating the technology, and the IESG may defer approval when a delay may facilitate obtaining such assurances. I note the "may", but still it feels like an important step was missed here. So: Was there an implicit conclusion that the IPR claims don't hinder the technology? Or did nobody check it out? Or did the WG decide consciously not to worry about it? Or is it actually fine to just ignore them? |
2021-08-11
|
08 | Murray Kucherawy | [Ballot comment] I support the DISCUSS positions of Lars, Warren, Martin, and Roman. I'm particularly interested in Martin's DISCUSS point about the two Experimental references … [Ballot comment] I support the DISCUSS positions of Lars, Warren, Martin, and Roman. I'm particularly interested in Martin's DISCUSS point about the two Experimental references and their statuses. That's a lot right there, so in addition from me, just some minor things: The answer to question 1 of the shepherd document is not complete. Section 1: * "... an on-path telemetry technique and consists in synchronizing ..." -- s/in/of/ * "... and therefore divide the packet ..." -- s/divide/dividing/ (must match "synchronizing" and "switching" earlier in the sentence) OLD: The threat model for the application of the Alternate Marking Method in an IPv6 domain is reported in Section 6. As for all the on-path telemetry technique, the only definitive solution is that this methodology MUST be applied in a controlled domain and therefore the application to untrusted domain is NOT RECOMMENDED. NEW: The threat model for the application of the Alternate Marking Method in an IPv6 domain is reported in Section 6. As with all on-path telemetry techniques, the only definitive solution is that this methodology MUST be applied in a controlled domain and therefore application to untrusted domains is NOT RECOMMENDED. Sections 2, 4, and 6 variably use "behavior" and "behaviour". I think you need to pick one and use it consistently. Same for "analyze" and "analyse" (though in different sections). |
2021-08-11
|
08 | Murray Kucherawy | [Ballot Position Update] New position, Discuss, has been recorded for Murray Kucherawy |
2021-08-11
|
08 | Benjamin Kaduk | [Ballot comment] My colleagues already made some good reviews, so I don't have any more comments to add at the Discuss level (though I will … [Ballot comment] My colleagues already made some good reviews, so I don't have any more comments to add at the Discuss level (though I will follow the resolution of the other reviews). I do have a number of COMMENT-level comments (plus some NITS-level remarks at the end that probably don't need individual responses). Section 1 application in an IPv6 domain. While the case of Segment Routing Header (SRH), defined in [RFC8754], is also discussed, it is valid for all the types of Routing Header (RH). Given that it's not required to use a routing header with this option, and the discussion in section 4 explicitly covers the ordering between destination option and (an arbitrary) routing header, I think it might be okay to drop this sentence. Section 2 The Alternate Marking Method requires a marking field. As mentioned, several alternatives have been analysed in [I-D.fioccola-v6ops-ipv6-alt-mark] such as IPv6 Extension Headers, IPv6 Address and Flow Label. If one follows the "replaced by" chain, it seems that draft-fioccola-v6ops-ipv6-alt-mark is listed as a direct predecessor of this document. So it seems a little odd to refer back to a previous version of this draft (without even acknowledging that it is a previous version of this work) for additional details on a topic that is also treated here in a summary form. Why not just eliminate the reference and include the needed information here (perhaps in an appendix if needed)? For what it's worth, I think that the summary in this section can stand on its own without need for further supporting references. Furthermore the Flow Label may be changed en route and this may also violate the measurement task. [...] My (hasty) reading of RFC 6437 is that such changes are strongly discouraged and only allowed in exceptional circumstances. Perhaps the description here should account for that? monitored flow. Flow Label and FlowMonID within the same packet are totally disjoint, have different scope, identify different flows, and are intended for different use cases. Can you explain a bit more (not necessarily in the document) what "identify different flows" means? It seems like if two identifiers are carried in the same packet they must in some sense identify the same thing, so I'm not sure what the different "flows" would be in this scenario. The rationale for the FlowMonID is further discussed in Section 5.3. This 20 bit field allows easy and flexible identification of the monitored flow and enables a finer granularity and improved measurement correlation. [...] I'm a bit confused at how "finer granularity" comes in -- if the FlowMonID is 20 bits, isn't that the same granularity as the 20-bit Flow Label? Section 2.1 [RFC8799] introduces the concept of specific limited domain solutions and, in this regard, it is reported the IPv6 Application of the Alternate Marking Method as an example. I think Roman already touched on this point as well, but RFC 8799 only introduces the concept; it's not the final word on the concept, and 8799 seems to expect that documents using the concept of a controlled domain will add on much more specifics about what is actually meant. Some scenarios may imply that the Alternate Marking Method is applied outside a controlled domain, either intentionally or unintentionally, but in these cases, IPsec authentication and encryption MUST be used. I appreciate the sentiment, but a hard MUST requirement for IPsec specifically may be needlessly limiting. Why would some other VPN technology that provides full packet confidentiality+integrity protection while traversing the external domain be insufficient? Section 4 Options Header to a slow processing path. In case of the AltMark data fields described in this document, the motivation to standardize a new Hop-by-Hop Option is that it is needed for OAM (Operations, Administration, and Maintenance). [...] It seems to also be worth mentioning here that the limitation of use to a controlled domain helps mitigate the risk of arbitrary nodes dropping packets with HbH options. Section 5 This section describes how the method operates. [RFC8321] introduces several alternatives but in this section the most applicable methods are reported and a new field is introduced to facilitate the deployment and improve the scalability. If only the "most applicable methods" are reported, and both RFC 8321 and this document say to prefer a batching strategy based on a fixed time interval, doesn't that make the batching strategy based on fixed packet count "not most applicable" and thus undeserving of mention at all in this document? Section 5.2 The same principle used to measure packet loss can be applied also to one-way delay measurement. Delay metrics MAY be calculated using the two possibilities: Again, how are there two possibilities that are both "most applicable methods"? In summary the approach with double marking is better than the approach with single marking. Moreover the two approaches can also be combined to have even more information and statistics on delay. It might be worth saying a little more about how the approaches can be "combined"; my current understanding seems more like they are both executed in parallel on the same input data, but they produce independent result values and any combination of those results is left to the system (or human) processing the results. Section 5.3 o First, it helps to reduce the per node configuration. Otherwise, each node needs to configure an access-control list (ACL) for each of the monitored flows. Moreover, using a flow identifier allows a flexible granularity for the flow definition. This seems to only be relevant in the case where there is definitely a central controller involved, if I'm understanding correctly -- if the source is assigning the FlowMonIDs the consumers will still need to look for those flows by ACL. So maybe this could be rephrased slightly to account for that. Section 5.3.1 of collision for 1206 flows. So, for more entropy, FlowMonID can either be combined with other identifying flow information in a packet (e.g. it is possible to consider the hashed 3-tuple Flow Label, Source and Destination addresses) or the FlowMonID size could be increased. This document is about to become a final, standards-track, RFC. I strongly suggest removing discussion of things that are not possible once the protocol becomes immortalized in an RFC (that is, increasing the FlowMonID size). Section 6 Thank you for putting so much effort into the security considerations section already! I have a few thoughts on potential additional topics to consider. Not necessarily something that needs to be discussed in the security considerations section itself, but the security considerations in practice will depend on whether the marking is always enabled for all flows, always enabled for a subset of flows, only enabled for specific flows on-demand, etc.. Some kind of scope-setting for the expected usage could be helpful to see, since the expected usage shapes what analysis has been done of the security properties. Separately, it is perhaps too banal to mention, but attacks on the reporting/consolidation of the statistics between the monitoring devices and the analysis platform can interfere with the proper functioning of the system. The channels used to report back flow statistics should be secured. There are also some considerations to note when the FlowMonIDs are centrally allocated by a controller -- the controller knows a lot about what traffic is flowing! That might make it the target of an attack, depending on the attacker goals. Another factor that comes into play when the controller (or anyone, really) is non-randomly assigning IDs, is that the actual structure of the ID allocation itself can cause issues -- for example, predictable sequential assignment can give an attacker insight into the rate of flow creation, what fraction of flows they have visibility into from their current vantage point, and makes attacks that are contingent on guessing the "next" identifier very feasible. The considerations in draft-gont-numeric-ids-sec-considerations seem to apply. Harm caused by the measurement: Alternate Marking implies I think Roman already touched on this to some extent, but the FlowMonID in the measurement option adds some privacy considerations that can in some cases mean that the measurement causes harm. single monitoring point. The only way for an attacker can be to eavesdrop on multiple monitoring points at the same time, because they have to do the same kind of calculation and aggregation as Alternate Marking requires, and, after that, it can finally gain information about the network performance, but this is not immediate. Just my own opinion, but I think this would be more useful if it stopped after "have to do the same kind of calculation and aggregation as Alternate Marking requires." That is, the attacker doesn't have an advantage over the rightful admin, but can get the same data; we don't need to say anything more, and the mention of "not immediate" is arguably misleading. Furthermore, in a pervasive surveillance attack, the information that can be derived over time is more. But the application of the Alternate Marking to a controlled domain helps to mitigate all the above aspects of privacy concerns. I suggest adding another clause or sentence about why/how the controlled domain mitigates the privacy concerns (perhaps just as a forward reference to the text currently two paragraphs later than this one, which might be easier to achieve if the security considerations were split into subsections). this document. As an example, the AltMark Option can be used as Hop- by-Hop or Destination Option and, in case of Destination Option, multiple domains may be traversed by the AltMark Option that is not confined to a single domain. In this case, the user, aware of the (This statement might be added to the list that Roman enumerated of places where we do/don't talk about being confined to a limited domain.) confined to a single domain. In this case, the user, aware of the kind of risks, may still want to use Alternate Marking for telemetry and test purposes but the inter-domain links need to be secured (e.g., by IPsec) in order to avoid external threats. For these (Interesting that here IPsec is only an "e.g." and not a MUST...even though the "MUST" is repeated in the following sentence! C.f. my remark on Section 2.1.) measurement. A detailed discussion about the threats against time protocols and how to mitigate them is presented in [RFC7384]. Also, NTS was recently published as RFC 8915; it might be worth mentioning here. Section 9.2 It's not really clear to me that RFCs 8321 and 8889 can be classified as informative. NITS Section 1 The Alternate Marking is an on-path telemetry technique and consists in synchronizing the measurements in different points of a network by switching the value of a marking bit and therefore divide the packet flow into batches. Each batch represents a measurable entity s/divide/dividing/, to match up with the conjugation of "synchronizing" and "switching". unambiguously recognizable by all network nodes along the path. By I think that "unambiguously" can fail in the face of extreme reording (relative to the marking window). in an IPv6 domain is reported in Section 6. As for all the on-path telemetry technique, the only definitive solution is that this s/all the on-path telemetry technique/all on-path telemetry techniques/ Section 2 Hop-by-Hop Option Header is also useful to signal to routers on the path to process the Alternate Marking. However, as said, routers will examine this option if properly configured. I think that "only" should be added, either for "will only examine" or "only if properly configured" (but not both). Furthermore the Flow Label may be changed en route and this may also violate the measurement task. [...] "violate the measurement task" is an unusual phrasing, and I'm not actually sure what meaning it's intended to convey. Perhaps it's something about invalidating the integrity of the measurement result? Section 4 In general, it is needed to perform both end to end and hop by hop measurements, and the Alternate Marking methodology allows, by definition, both performance measurements. But, in many cases the end-to-end measurement is not enough and it is required also the hop- by-hop measurement, so the most complete choice is the Hop-by-Hop Options Header. The paragraph structure here doesn't make much sense: we say that in general, both (end-to-end and hop-by-hop) measurements are possible, but then follow up with a note that "in many cases end-to-end is not enough". There's no previous situation described where only end-to-end is possible that merits this comparison. It seems that some specific mention of Destination Options would be needed in order to be able to make such a comparison. Section 5.1 single batch between any two nodes. Each batch represents a measurable entity unambiguously recognizable by all network nodes along the path. (Same remark about "unambiguous" as above) It is worth mentioning that the length of the batches is considered stable over time in the previous figure. In theory, it is possible I'd consider "duration" rather than "length", here (indeed, the figure shows batches of both 10 and 11 packets, and possibly 9 as well if "batch 1" is not considered to be truncated Section 6 The FlowMonID field is used in the AltMark Option as identifier of the monitored flow. It represents a more sensitive information "identifier" needs an article; I'm not sure whether "a" or "the" would better match the intended meaning. |
2021-08-11
|
08 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2021-08-11
|
08 | Warren Kumari | [Ballot discuss] I must be missing something fairly fundamental here. "As stated above, the precondition for the application of the Alternate Marking is that … [Ballot discuss] I must be missing something fairly fundamental here. "As stated above, the precondition for the application of the Alternate Marking is that it MUST be applied in specific controlled domains, thus confining the potential attack vectors within the network domain. [RFC8799] analyzes and discusses the trend towards network behaviors that can be applied only within a limited domain. This is due to the specific set of requirements especially related to security, network management, policies and options supported which may vary between such limited domains. A limited administrative domain provides the network administrator with the means to select, monitor and control the access to the network, making it a trusted domain. In this regard it is expected to enforce policies at the domain boundaries to filter both external packets with AltMark Option entering the domain and internal packets with AltMark Option leaving the domain. Therefore the trusted domain is unlikely subject to hijacking of packets since packets with AltMark Option are processed and used only within the controlled domain." The above says that this must only be done in a limited/controlled domain, and that operators are: "expected to enforce policies at the domain boundaries to filter both external packets with AltMark Option entering the domain and internal packets with AltMark Option leaving the domain.". The "only do this in in limited domain" seems to simply punt on the security concerns / considerations. What is an operator supposed to do if their device doesn't understand this option? Are you really suggesting that everyone needs to do though and update edge firewall filters everywhere to block this? What happens when a filter is unintentionally missed? Or when the device cannot filter N headers deep? [edit firewall family inet6 filter altmark term demo] wkumari@rtr2.pao# set from extension-header ? Possible completions: Range of values [ Open a set of values ah Authentication header any Any extension header dstopts Destination options esp Encapsulating security payload fragment Fragment hop-by-hop Hop by hop options mobility Mobility routing Routing Yes, many networks use automation to apply filters, but it is still unreasonable to force operators to have to keep updating and deploying new filters when new protocols are created. |
2021-08-11
|
08 | Warren Kumari | [Ballot Position Update] New position, Discuss, has been recorded for Warren Kumari |
2021-08-11
|
08 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2021-08-11
|
08 | Éric Vyncke | [Ballot discuss] Thank you for the work put into this document. Special thanks to Ole Trøan for his shepherd's write-up, which contains a good summary … [Ballot discuss] Thank you for the work put into this document. Special thanks to Ole Trøan for his shepherd's write-up, which contains a good summary of the WG consensus and the SW (?) implementation status. Thanks as well to Bob Halley for his INT directorate review. Please find below some blocking DISCUSS points, some non-blocking COMMENT points (but replies would be appreciated). I also agree with DISCUSS points by other ADs: - Lars's one about the size and usefulness of FlowMonID (see my very similar point) - Roman's one about the inconsistencies about limited domain (from my point of view, this should not be limited to a single domain) All in all, I strongly suggest to change the intended status of this document to 'experimental' as this document builds on experimental RFCs. I hope that this helps to improve the document, Regards, -éric == DISCUSS == This discussion already happened in the 6MAN WG but I still have to be convinced that hop-by-hop is a good idea at all. The fate of packets with HbH is unknown at best and, IMHO, this is a wrong use of HbH because the forwarding/processing of packets is NOT influenced at all by the AltMark option. What is required is a simple 'marking/coloring', which could be at any place in a packet (including destination option). The only benefit of HbH is its location just after the IPv6 header. After all, existing devices can measure and generate IPFIX records in hardware/fastpath by inspecting at the bare minimum the 5-tuple and many devices can also parse extension headers in the fast path (of course not processing HbH in this case). I.e., finding the marking in the Dest Option is probably much easier and doable in current hardware rather than using HbH as HbH forces a software processing. -- Section 2 -- "In the end, [I-D.fioccola-v6ops-ipv6-alt-mark] demonstrated that a new Hop-by-Hop or a new Destination Option was the best approach." The above draft has not been published and is even expired for 2 years now... so please remove the 'demonstrated' as there is no proof at all ;-) -- Section 4 -- Please remove "the destination node removes it" as there is no reason to remove it. Extension headers are usually not presented / used by upper layers anyway. |
2021-08-11
|
08 | Éric Vyncke | [Ballot comment] -- Section 2.1 -- While I agree with my fellow AD about the inconsistencies of the text around 'limited domain' (and being inconsistent … [Ballot comment] -- Section 2.1 -- While I agree with my fellow AD about the inconsistencies of the text around 'limited domain' (and being inconsistent deserves a blocking DISCUSS), I do not agree with this section as I do not see any harm to extend this marking outside of a single domain, marked packets with this specification can traverse the whole Internet without causing any harm and not opening for any attack on the transit nodes. (See also my point about Hop-by-hop) E.g., packets from organisation A can traverse networks of organizations B, C, ..., Z to reach another site of organization A and still provide useful measurements for A without causing harm to B, C, ..., Z. Of course the survivability of those marked packets is not guaranteed. -- Section 3.1 -- Is there any reason why the FlowMonID is 20 bit long ? Exactly as the 20-bit Flow Label of the IPv6 header... See my comments for section 5.3 s/Unrecognized Types MUST be ignored on receipt./Unrecognized Types MUST be ignored on processing./ as the option should be processed not only by the destination node. -- Section 5 -- This section (in a standard track I-D) repeats many things from experimental RFCs... This is really confusing and, while I am usually not dogmatic, I support my fellow AD on this point. Moreover, repeating contents from other docs can only introduce inconsistencies among docs => suggest to remove section 5.1 and 5.2. -- Section 5.3 -- The general reasons of using a 20-bit FlowMonID appear quite weak to me with the risk of collision being very high, e.g., in a DC with thousands of VM and millions of containers there will be collisions rendering this field useless. Strongly suggest to make its use optional |
2021-08-11
|
08 | Éric Vyncke | [Ballot Position Update] New position, Discuss, has been recorded for Éric Vyncke |
2021-08-10
|
08 | Martin Duke | [Ballot discuss] I have some concerns about this approach, plus some points of confusion that hopefully will clear up quickly. I support Lars's first two … [Ballot discuss] I have some concerns about this approach, plus some points of confusion that hopefully will clear up quickly. I support Lars's first two DISCUSS points. (edited) (1) The precise use case is unclear to me. An end-user (not in the controlled domain) generates an IPv6 packet, and I gather some sort of middlebox then inserts the header if it meets some criteria (perhaps that the destination IP is also within the domain). If this is correct, I would like to check with the experts if a non-endpoint inserting a header is compliant with RFC8200. Also, this should be written down somewhere. If not correct, I have many more questions. (2) The draft informatively references the (Experimental) RFCs 8321 and 8889 and covers some of the same ground, but as a Proposed Standard. Is part of the purpose here to update or obsolete these RFCs? (3) Are there any restrictions on FlowMon IDs? Need these be pseudorandom, or can they encode information in the clear? (4) Sec 5.1: When using timer-based batches, I gather you use times well in excess of potential reordering. If using a counter-based method, how does the measurement account for potential reordering? There could easily be a very large instantaneous burst followed by a path change that lowered the latency. |
2021-08-10
|
08 | Martin Duke | Ballot discuss text updated for Martin Duke |
2021-08-10
|
08 | Alvaro Retana | [Ballot comment] (1) I support the DISCUSS positions from Lars, Roman, and Martin. (1a) Of special concern to me is Martin's point about the relationship … [Ballot comment] (1) I support the DISCUSS positions from Lars, Roman, and Martin. (1a) Of special concern to me is Martin's point about the relationship between this document and rfc8321/8889, and the potential ability to reference this work without proper review by the ippm WG. Note that neither RFC is explicit about the criteria to complete the respective experiments; the Shepherd writeup for rfc8321 [a] states that "the measurement utility of this extension still is to be demonstrated at a variety of scales in a plurality of network conditions." Furthermore, I am not aware of discussions about the maturity of rfc8321 in the ippm WG. [a] https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark/shepherdwriteup/ (2) There are several references to I-D.fioccola-v6ops-ipv6-alt-mark, which was replaced by draft-fz-6man-ipv6-alt-mark and ultimately by this document. IOW, it looks like this document refers to an old version of itself. Since the references are mostly about analysis made in the early drafts, it may be better to include some of that in an appendix instead. |
2021-08-10
|
08 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2021-08-10
|
08 | Christopher Wood | Request for Telechat review by SECDIR Completed: Ready. Reviewer: Christopher Wood. Sent review to list. |
2021-08-09
|
08 | Martin Duke | [Ballot discuss] I have some concerns about this approach, plus some points of confusion that hopefully will clear up quickly. I support Lars's first two … [Ballot discuss] I have some concerns about this approach, plus some points of confusion that hopefully will clear up quickly. I support Lars's first two DISCUSS points. (1) I am unclear about the relationship between limited domains and the prohibition against modifying either option before the destination. Is the intent that (a) this is only used for traffic that begins and ends in the domain; (b) user traffic is encapsulated with an outer IPv6 header that is removed prior to domain exit; or (c) the "destination" actually means the egress point from the domain? (2) Relatedly, if the source nodes are user-generated packets, how is this in practice a limited domain? Source nodes have enormous power to degrade the measurement by sending packets that fill the entire FlowMon space with only 1M packets, which not only consumes router resources but also pollutes every single measurement in the domain. (3) The draft informatively references the (Experimental) RFCs 8321 and 8889 and covers some of the same ground, but as a Proposed Standard. Is part of the purpose here to update these RFCs? For other measurement techniques, we've had a generic measurement draft in IPPM and encapsulations in the appropriate protocol-specific groups like 6man. Why was that approach not taken here? Will future encapsulations of alternate marking refer to this one normatively on how to conduct the measurement? (4) Are there any restrictions on FlowMon IDs? Need these be pseudorandom, or can they encode information in the clear? (5) I don't understand the basic motivation for using HBH options if these can result in the packet being diverted to the slow path on intermediate nodes. This seems like a major drawback for a delay measurement! (6) Sec 5.1: When using timer-based batches, I gather you use times well in excess of potential reordering. If using a counter-based method, how does the measurement account for potential reordering? There could easily be a very large instantaneous burst followed by a path change that lowered the latency. |
2021-08-09
|
08 | Martin Duke | [Ballot comment] Thanks to Yoshi for the TSVART review. |
2021-08-09
|
08 | Martin Duke | [Ballot Position Update] New position, Discuss, has been recorded for Martin Duke |
2021-08-09
|
08 | Roman Danyliw | [Ballot discuss] Please provide consistent guidance on where this methodology can be used. Consider: (a) Section 2.1. “Therefore, the IPv6 application of the Alternate Marking … [Ballot discuss] Please provide consistent guidance on where this methodology can be used. Consider: (a) Section 2.1. “Therefore, the IPv6 application of the Alternate Marking Method MUST NOT be deployed outside a controlled domain.” (b) Section 2.1. “Some scenarios may imply that the Alternate Marking Method is applied outside a controlled domain, either intentionally or unintentionally, but in these cases, IPsec authentication and encryption MUST be used.” (c) Section 6. “This document aims to apply a method to perform measurements that does not directly affect Internet security nor applications that run on the Internet.” (d) Section 6. “As stated above, the precondition for the application of the Alternate Marking is that it MUST be applied in specific controlled domains, thus confining the potential attack vectors within the network domain. (e) Section 6. “In this case, the user, aware of the kind of risks, may still want to use Alternate Marking for telemetry and test purposes but the inter-domain links need to be secured (e.g., by IPsec) in order to avoid external threats. For these specific scenarios the application of the Alternate Marking Method outside a controlled domain is possible but IPsec through AH (Authentication Header) or ESP (Encapsulating Security Payload) MUST be used.” (a) and (d) seem to very clear that this approach MUST only be used in a controlled domain. However (b) and (d) seem to suggest that this prohibition is at best a “SHOULD”. If (b) and (d) are true, than (c) not affecting applications on the internet might not be true. ** Section 6. Thanks for mentioning “At the management plane, attacks can be set up by misconfiguring or by maliciously configuring AltMark Option.” Please be clearer on what these attacks could look like. Would these include: -- using the FlowMonId as a tracking identifier? -- (Likely possible at both the data and management plane would be a) covert channel between the sender and an on-path observer? |
2021-08-09
|
08 | Roman Danyliw | [Ballot comment] Thank you to Chris Wood for the SECDIR review and to the authors for responding to it. ** Is those a tighter applicability … [Ballot comment] Thank you to Chris Wood for the SECDIR review and to the authors for responding to it. ** Is those a tighter applicability statement than can be applied where this approach will be used. A few things are said: (a) Section 1. “As for all the on-path telemetry technique, the only definitive solution is that this methodology MUST be applied in a controlled domain ...” (b) Section 1. “... therefore the application to untrusted domain is NOT RECOMMENDED” (c) Section 6. “As stated above, the precondition for the application of the Alternate Marking is that it MUST be applied in specific controlled domains, thus confining the potential attack vectors within the network domain. [RFC8799] analyzes and discusses the trend towards network behaviors that can be applied only within a limited domain.” -- While citing RFC8799 is helpful as the basis of phrase “controlled domain”, that reference also explains that “The requirements of limited domains will depend on the deployment scenario. Policies, default parameters, and the options supported may vary. Also, the style of network management may vary between a completely unmanaged network, one with fully autonomic management, one with traditional central management, and mixtures of the above. Finally, the requirements and solutions for security and privacy may vary.” Put in another way, unless further specified, RFC8799 doesn’t actually say anything about the properties of the network except that it isn’t the Internet. Will it be a managed network? A single administrative domain? Etc. -- Per (b), stating “untrusted domain” (thanks for responding to the SECDIR reviewer with this) is orthogonal to “controlled domain”. Being “controlled” doesn’t suggest “trusted” or “untrusted”. Can “untrusted” be elaborated on? ** Section 2.1. Per “Some scenarios may imply that the Altenative Marking Method is applied outside a controlled domain ... unintentionally, ...”, it seems odd to provide normative guidance for unintentional behavior. ** Section 2.1. Per “It is RECOMMENDED that an implementation can be able to reject packets that carry Alternate Marking data and are entering or leaving the controlled domains”, what is the “implementation” in this case? I was under the impression that these are end-node applying this marking. However, it seems like routers/firewalls would be the ones enforcing the policy of dropping these packets. ** Section 5.3. Per “The FlowMon identifier field is to uniquely identify a monitored flow within the measurement domain”, what is a measurement domain? What is the relationship between it and the controlled domain in which it is supposed to be operating? Perhaps there is a definition for “measurement domain” that can be cited? ** Section 6. As already discussed in Section 4, it is RECOMMENDED that the AltMark Option does not affect the throughput and therefore the user experience. This text appears to be stating a desired functional requirement of the AltMark not having an impact on the network, but the practical guidance to an adopter isn’t clear to me. ** Various editorial comments -- Section 1. Editorial. Per “The Alternate Marking is an on-path telemetry technique and consists in synchronizing …", there is a grammar nit with “... and consists in synchronizing ...” but I don’t follow the intent enough to provide a suggestion. -- Section 5.1. Editorial. Per “The measurement of the packet loss is really straightforward”, straightforward in comparison to what? -- Section 5.1. Editorial. s/and and/and/ -- Section 5.3. Editorial. s/if the/If the/ -- Section 6. Editorial. s/or insert deliberately/or deliberately insert/ |
2021-08-09
|
08 | Roman Danyliw | [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw |
2021-08-06
|
08 | Lars Eggert | [Ballot discuss] Section 2.1. , paragraph 4, discuss: > Therefore, the IPv6 application of the Alternate Marking Method MUST > NOT be deployed … [Ballot discuss] Section 2.1. , paragraph 4, discuss: > Therefore, the IPv6 application of the Alternate Marking Method MUST > NOT be deployed outside a controlled domain. That's not what Section 6 says, which allows use outside a controlled domain (across the Internet) if protection is applied? Section 2.1. , paragraph 4, discuss: > Some scenarios may imply that the Alternate Marking Method is applied > outside a controlled domain, either intentionally or unintentionally, > but in these cases, IPsec authentication and encryption MUST be used. How can one require use of IPsec for an unintentional use outside of a controlled domain? If the header leaks by accident, surely it's unreasonable to expect that IPsec had been set up to catch any and all such possible leakage? Also (as a comment), if IPsec is required by this document, it needs to be normatively cited. Section 5.3.1. , paragraph 2, discuss: > It is important to note that if the 20 bit FlowMonID is set > independently and pseudo randomly there is a chance of collision. > Indeed, by using the well-known birthday problem in probability > theory, if the 20 bit FlowMonID is set independently and pseudo > randomly without any additional input entropy, there is a 50% chance > of collision for 1206 flows. So, for more entropy, FlowMonID can > either be combined with other identifying flow information in a > packet (e.g. it is possible to consider the hashed 3-tuple Flow > Label, Source and Destination addresses) or the FlowMonID size could > be increased. It seems odd to define a dedicated FlowMonID, but make it so short that it is basically not usable in many realistic scenarios. If other parts of the packet headers need to be inspected to disambiguate FlowMonID collisions, this (1) should at least be more carefully specified in this document (since every node will need to do it in the same way) but (2) probably argues for a much longer FlowMonID - why not make it 64 bits or longer? The IANA review of this document seems to not have concluded yet; I am holding a DISCUSS for IANA until it has. |
2021-08-06
|
08 | Lars Eggert | [Ballot comment] Section 5.1. , paragraph 4, comment: > issues. Specifically, if the effects of network delay are ignored, > the condition to … [Ballot comment] Section 5.1. , paragraph 4, comment: > issues. Specifically, if the effects of network delay are ignored, > the condition to implement the methodology is that the clocks in > different nodes MUST be synchronized to the same clock reference with > an accuracy of +/- B/2 time units, where B is the fixed time duration > of the block. What is a block? Do you mean a batch? I see that RFC8321 uses "block", should this document adopt that term? Also, how can a block (of packets) have a "fixed time duration"? Is this supposed to mean transmission time of the block at line-rate? What about pacing? ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 2.1. , paragraph 4, nit: - an implementation can be able to reject packets that carry Alternate - --------------- + an implementation rejects packets that carry Alternate + + Section 3.1. , paragraph 5, nit: - o Option Type: 8 bit identifier of the type of Option that needs to - ^ + o Option Type: 8-bit identifier of the type of Option that needs to + ^ Section 3.1. , paragraph 7, nit: - o FlowMonID: 20 bits unsigned integer. The FlowMon identifier is - ^ - + o FlowMonID: 20-bit unsigned integer. The FlowMon identifier is + ^ Section 3.1. , paragraph 7, nit: - picked 20 bit since it is a reasonable value and a good compromise + picked as 20 bit since it is a reasonable value and a good compromise + +++ Section 4. , paragraph 6, nit: - are useable when SRv6 header is present. Because SRv6 is implemented - - + are usable when SRv6 header is present. Because SRv6 is implemented Section 1. , paragraph 3, nit: > sely measure the packet loss. In a similar way the alternation of the values > ^^^^^^^^^^^^^^^^ Consider replacing this phrase with the adverb "similarly" to avoid wordiness. Section 1.1. , paragraph 1, nit: > I-D.fioccola-v6ops-ipv6-alt-mark] analyzed and discussed all the available po > ^^^^^^^^ Do not mix variants of the same word ("analyze" and "analyse") within a single text. Section 2. , paragraph 8, nit: > and on the nodes that support it. However it is important to mention that th > ^^^^^^^ A comma may be missing after the conjunctive/linking adverb "However". Section 2. , paragraph 11, nit: > intent and forwarding behaviour. Furthermore the Flow Label may be changed en > ^^^^^^^^^^^ A comma may be missing after the conjunctive/linking adverb "Furthermore". Section 2.1. , paragraph 2, nit: > f IPsec for an unintentional use outside of a controlled domain? If the head > ^^^^^^^^^^ This phrase is redundant. Consider using "outside". Section 3.1. , paragraph 1, nit: > rd-highest-order bit specifies whether or not the Option Data can change en r > ^^^^^^^^^^^^^^ Consider shortening this phrase to just "whether". It is correct though if you mean "regardless of whether". Section 3.1. , paragraph 4, nit: > ssed below, it has been picked as 20 bit since it is a reasonable value and a > ^^^ Possible agreement error. The noun "bit" seems to be countable. Section 4. , paragraph 6, nit: > intermediate node can read it or not but this does not affect the packet beh > ^^^^ Use a comma before "but" if it connects two independent clauses (unless they are closely connected and short). Section 4. , paragraph 8, nit: > an-hbh-processing], this means "skip if do not recognize and data do not cha > ^^ It seems that a pronoun is missing. Section 4. , paragraph 12, nit: > most applicable methods are reported and a new field is introduced to facili > ^^^^ Use a comma before "and" if it connects two independent clauses (unless they are closely connected and short). Section 5.1. , paragraph 4, nit: > ge the length of batches over time and and among different flows for more fle > ^^^^^^^ Possible typo: you repeated a word. Section 5.1. , paragraph 9, nit: > rage timestamp for each batch. In addition the information is limited to a me > ^^^^^^^^ A comma may be missing after the conjunctive/linking adverb "addition". Section 5.2. , paragraph 3, nit: > the approach with single marking. Moreover the two approaches can also be com > ^^^^^^^^ A comma may be missing after the conjunctive/linking adverb "Moreover". Section 5.2. , paragraph 7, nit: > table in most of the applications. Indeed with 20 bits the number of combinat > ^^^^^^ A comma may be missing after the conjunctive/linking adverb "Indeed". Section 5.3.1. , paragraph 3, nit: > r of IPv6 packets by the source node but this must be performed in a way tha > ^^^^ Use a comma before "but" if it connects two independent clauses (unless they are closely connected and short). Section 6. , paragraph 2, nit: > privacy concerns also need to be analyzed even if the method only relies on > ^^^^^^^^ Do not mix variants of the same word ("analyze" and "analyse") within a single text. Section 6. , paragraph 4, nit: > paths. AltMark Option contains two kind of metadata: the marking bits (L and > ^^^^ Possible agreement error. The noun "kind" seems to be countable. Section 6. , paragraph 5, nit: > n data-plane traffic is difficult. Indeed an attacker cannot gain information > ^^^^^^ A comma may be missing after the conjunctive/linking adverb "Indeed". Section 6. , paragraph 6, nit: > hin the network domain. [RFC8799] analyzes and discusses the trend towards ne > ^^^^^^^^ Do not mix variants of the same word ("analyze" and "analyse") within a single text. Section 6. , paragraph 7, nit: > tMark Option leaving the domain. Therefore the trusted domain is unlikely su > ^^^^^^^^^ A comma may be missing after the conjunctive/linking adverb "Therefore". Section 6. , paragraph 7, nit: > ome packets might exceed the MTU. However the relative small size (48 bit in > ^^^^^^^ A comma may be missing after the conjunctive/linking adverb "However". Section 6. , paragraph 9, nit: > described in this document relies on an time synchronization protocol. Thus, > ^^ Use "a" instead of "an" if the following word doesn't start with a vowel sound, e.g. "a sentence", "a university". Document references draft-peng-v6ops-hbh-04, but -05 is the latest available revision. Document references draft-fioccola-v6ops-ipv6-alt-mark-01, but -08 is the latest available revision. |
2021-08-06
|
08 | Lars Eggert | [Ballot Position Update] New position, Discuss, has been recorded for Lars Eggert |
2021-08-05
|
08 | Bob Halley | Request for Telechat review by INTDIR Completed: Ready. Reviewer: Bob Halley. Sent review to list. |
2021-07-29
|
08 | Carlos Jesús Bernardos | Request for Telechat review by INTDIR is assigned to Bob Halley |
2021-07-29
|
08 | Carlos Jesús Bernardos | Request for Telechat review by INTDIR is assigned to Bob Halley |
2021-07-29
|
08 | Éric Vyncke | Requested Telechat review by INTDIR |
2021-07-29
|
08 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Christopher Wood |
2021-07-29
|
08 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Christopher Wood |
2021-07-28
|
08 | Alvaro Retana | Requested Telechat review by RTGDIR |
2021-07-26
|
08 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2021-07-26
|
08 | Giuseppe Fioccola | New version available: draft-ietf-6man-ipv6-alt-mark-08.txt |
2021-07-26
|
08 | (System) | New version approved |
2021-07-26
|
08 | (System) | Request for posting confirmation emailed to previous authors: Fengwei Qin , Giuseppe Fioccola , Mauro Cociglio , Ran Pang , Tianran Zhou |
2021-07-26
|
08 | Giuseppe Fioccola | Uploaded new revision |
2021-07-23
|
07 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2021-07-23
|
07 | Jean Mahoney | Request for Telechat review by GENART is assigned to Stewart Bryant |
2021-07-23
|
07 | Jean Mahoney | Request for Telechat review by GENART is assigned to Stewart Bryant |
2021-07-22
|
07 | Cindy Morgan | Placed on agenda for telechat - 2021-08-12 |
2021-07-22
|
07 | Erik Kline | Ballot has been issued |
2021-07-22
|
07 | Erik Kline | [Ballot Position Update] New position, Yes, has been recorded for Erik Kline |
2021-07-22
|
07 | Erik Kline | Created "Approve" ballot |
2021-07-22
|
07 | Erik Kline | IESG state changed to IESG Evaluation from Waiting for Writeup |
2021-07-22
|
07 | Erik Kline | Ballot writeup was changed |
2021-06-22
|
07 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2021-06-22
|
07 | Giuseppe Fioccola | New version available: draft-ietf-6man-ipv6-alt-mark-07.txt |
2021-06-22
|
07 | (System) | New version approved |
2021-06-22
|
07 | (System) | Request for posting confirmation emailed to previous authors: Fengwei Qin , Giuseppe Fioccola , Mauro Cociglio , Ran Pang , Tianran Zhou |
2021-06-22
|
07 | Giuseppe Fioccola | Uploaded new revision |
2021-06-16
|
06 | Yoshifumi Nishida | Request for Last Call review by TSVART Completed: On the Right Track. Reviewer: Yoshifumi Nishida. Sent review to list. |
2021-06-15
|
06 | Christopher Wood | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Christopher Wood. Sent review to list. |
2021-06-15
|
06 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2021-06-09
|
06 | Magnus Westerlund | Assignment of request for Last Call review by TSVART to Tommy Pauly was withdrawn |
2021-06-09
|
06 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Yoshifumi Nishida |
2021-06-09
|
06 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Yoshifumi Nishida |
2021-06-07
|
06 | Stewart Bryant | Request for Last Call review by GENART Completed: Not Ready. Reviewer: Stewart Bryant. Sent review to list. |
2021-06-07
|
06 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Tommy Pauly |
2021-06-07
|
06 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Tommy Pauly |
2021-06-04
|
06 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2021-06-04
|
06 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-6man-ipv6-alt-mark-06. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-6man-ipv6-alt-mark-06. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete. In the Destination Options and Hop-by-Hop Options registry on the Internet Protocol Version 6 (IPv6) Parameters registry page located at: https://www.iana.org/assignments/ipv6-parameters/ a new registration will be made as follows: Hex Value Binary Value Description Reference act chg rest -----------------------+---------------+--------------------+------------- [ TBD-at-Registration ] 00 0 [TBD} AltMark [ RFC-to-be ] The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2021-06-03
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Stewart Bryant |
2021-06-03
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Stewart Bryant |
2021-06-03
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Christopher Wood |
2021-06-03
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Christopher Wood |
2021-06-03
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Victor Kuarsingh |
2021-06-03
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Victor Kuarsingh |
2021-06-01
|
06 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2021-06-01
|
06 | Cindy Morgan | The following Last Call announcement was sent out (ends 2021-06-15): From: The IESG To: IETF-Announce CC: 6man-chairs@ietf.org, bob.hinden@gmail.com, draft-ietf-6man-ipv6-alt-mark@ietf.org, ek.ietf@gmail.com, ipv6@ietf.org … The following Last Call announcement was sent out (ends 2021-06-15): From: The IESG To: IETF-Announce CC: 6man-chairs@ietf.org, bob.hinden@gmail.com, draft-ietf-6man-ipv6-alt-mark@ietf.org, ek.ietf@gmail.com, ipv6@ietf.org, otroan@employees.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (IPv6 Application of the Alternate Marking Method) to Proposed Standard The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'IPv6 Application of the Alternate Marking Method' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2021-06-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes how the Alternate Marking Method can be used as a passive performance measurement tool in an IPv6 domain. It defines a new Extension Header Option to encode alternate marking information in both the Hop-by-Hop Options Header and Destination Options Header. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-alt-mark/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3650/ https://datatracker.ietf.org/ipr/3325/ |
2021-06-01
|
06 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2021-06-01
|
06 | Erik Kline | Last call was requested |
2021-06-01
|
06 | Erik Kline | Ballot approval text was generated |
2021-06-01
|
06 | Erik Kline | Ballot writeup was generated |
2021-06-01
|
06 | (System) | Changed action holders to Erik Kline (IESG state changed) |
2021-06-01
|
06 | Erik Kline | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2021-06-01
|
06 | Erik Kline | Last call announcement was generated |
2021-06-01
|
06 | Ole Trøan | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed standard. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document describes how the Alternate Marking Method can be used as a passive performance measurement tool in an IPv6 domain. It defines a new Extension Header Option to encode alternate marking information in both the Hop-by-Hop Options Header and Destination Options Header. Working Group Summary: This has had discussion on the ipv6 list and detailed comments were received from several people. General support for advancing this document. Document Quality: There is at least one commercial implementation of alternate marking for MPLS and SRv6. An implementation of this draft (alternative marking for HBH and DestOpt options) as a proof of concept is in progress. This implementation is using an experimental code point. Personnel: Shepherd: Ole Troan AD: Erik Kline (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. Greg Mirsky and Brian Carpenter reviewed the document as part of the WG last call. The 6man chairs (including shepherd) reviewed the document in detail and provided comments that were incorporated in the draft (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. Extension header option format reviewed by 6man. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Yes, there are two IPRs filed. No working group discussion has been had. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is good support among the interested individuals. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No nits found. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). IANA section has been reviewed. The correct IANA registries are identified. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. N/A. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? N/A |
2021-05-31
|
06 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-05-31
|
06 | Giuseppe Fioccola | New version available: draft-ietf-6man-ipv6-alt-mark-06.txt |
2021-05-31
|
06 | (System) | New version approved |
2021-05-31
|
06 | (System) | Request for posting confirmation emailed to previous authors: Fengwei Qin , Giuseppe Fioccola , Mauro Cociglio , Ran Pang , Tianran Zhou |
2021-05-31
|
06 | Giuseppe Fioccola | Uploaded new revision |
2021-05-29
|
05 | Erik Kline | [S1] [nit] * s/often referred as/often referred to as/ [S2] [question] * "..., anyway it is to be expected that some routers cannot process it … [S1] [nit] * s/often referred as/often referred to as/ [S2] [question] * "..., anyway it is to be expected that some routers cannot process it unless explicitly configured" doesn't strike me as grammatically correct and perhaps a run-on sentence. Is the intention to say that routers are expected to ignore the option unless configured (i.e. for performance reasons)? If so, consider splitting this paragraph into two sentences, with the 2nd being something like: ". It is expected that routers will ignore this option unless explicitly configured to process it." (something similar to the text in section 4) [S2] [question] * ", and associate different uses." seems a bit unclear to me. Does mean something like "are intended for different use cases."? [S2] [nit] * s/the the uniqueness/the uniqueness/ [S2] [discuss] * "and this could also happen to the IP addresses that can change due to NAT" (and in the subsequent sentence) How did IPv6 NAT find its way into this discussion? Unless it is somehow critical to open up this discussion, I'd recommend just removing mention of it. [S4] [nit] * "by every node that is an identity in the SR path" I'm sure "identity" is the best word here. Perhaps "that is identified by the SR path"? [S4] [question] * The intended meaning of the final paragraph of this section eludes me. What is an example of a "non-conventional application" of a Dest option that has a similar effect to an HbH option? [S6] [question] * Can you explain how "network reconnaissance through passive eavesdropping on data-plane traffic does not allow attackers to gain information about the network performance"? It seems to me that an eavesdropping observer would have all the same information that src and dst do for inferring performance...yes? (In the case of an HbH option, each on-path router is indistinguishable from an eavesdropping observer?) [S7] [nit] * "assignments" -> "assignment", I think, since it appears the doc is only requesting a single assignment from a single registry. |
2021-05-29
|
05 | (System) | Changed action holders to Erik Kline, Mauro Cociglio, Tianran Zhou, Giuseppe Fioccola, Fengwei Qin, Ran Pang (IESG state changed) |
2021-05-29
|
05 | Erik Kline | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2021-05-29
|
05 | (System) | Changed action holders to Erik Kline (IESG state changed) |
2021-05-29
|
05 | Erik Kline | IESG state changed to AD Evaluation from Publication Requested |
2021-05-28
|
05 | Ole Trøan | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed standard. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document describes how the Alternate Marking Method can be used as a passive performance measurement tool in an IPv6 domain. It defines a new Extension Header Option to encode alternate marking information in both the Hop-by-Hop Options Header and Destination Options Header. Working Group Summary: This has had discussion on the ipv6 list and detailed comments were received from several people. General support for advancing this document. Document Quality: There is at least one commercial implementation of alternate marking for MPLS and SRv6. An implementation of this draft (alternative marking for HBH and DestOpt options) as a proof of concept is in progress. Personnel: Shepherd: Ole Troan AD: Erik Kline (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. Greg Mirsky and Brian Carpenter reviewed the document as part of the WG last call. The 6man chairs (including shepherd) reviewed the document in detail and provided comments that were incorporated in the draft (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. Extension header option format reviewed by 6man. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Yes, there are two IPRs filed. No working group discussion has been had. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is good support among the interested individuals. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No nits found. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). IANA section has been reviewed. The correct IANA registries are identified. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. N/A. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? N/A |
2021-05-28
|
05 | Ole Trøan | Responsible AD changed to Erik Kline |
2021-05-28
|
05 | Ole Trøan | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2021-05-28
|
05 | Ole Trøan | IESG state changed to Publication Requested from I-D Exists |
2021-05-28
|
05 | Ole Trøan | IESG process started in state Publication Requested |
2021-05-28
|
05 | Ole Trøan | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed standard. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document describes how the Alternate Marking Method can be used as a passive performance measurement tool in an IPv6 domain. It defines a new Extension Header Option to encode alternate marking information in both the Hop-by-Hop Options Header and Destination Options Header. Working Group Summary: This has had discussion on the ipv6 list and detailed comments were received from several people. General support for advancing this document. Document Quality: There is at least one commercial implementation of alternate marking for MPLS and SRv6. An implementation of this draft (alternative marking for HBH and DestOpt options) as a proof of concept is in progress. Personnel: Shepherd: Ole Troan AD: Erik Kline (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. Greg Mirsky and Brian Carpenter reviewed the document as part of the WG last call. The 6man chairs (including shepherd) reviewed the document in detail and provided comments that were incorporated in the draft (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. Extension header option format reviewed by 6man. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Yes, there are two IPRs filed. No working group discussion has been had. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is good support among the interested individuals. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No nits found. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). IANA section has been reviewed. The correct IANA registries are identified. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. N/A. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? N/A |
2021-05-26
|
05 | Ole Trøan | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed standard. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document describes how the Alternate Marking Method can be used as a passive performance measurement tool in an IPv6 domain. It defines a new Extension Header Option to encode alternate marking information in both the Hop-by-Hop Options Header and Destination Options Header. Working Group Summary: Nothing to note. Document Quality: There is at least one commercial implementation of alternate marking for MPLS and SRv6. An implementation of this draft (alternative marking for HBH and DestOpt options) as a proof of concept is in progress. Personnel: Shepherd: Ole Troan AD: Erik Kline (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. Greg Mirsky and Brian Carpenter reviewed the document as part of the WG last call. The 6man chairs (including shepherd) reviewed the document in detail. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. Extension header option format reviewed by 6man. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Yes, there are two IPRs filed. No working group discussion has been had. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is good support among the interested individuals. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No nits found. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). IANA section has been reviewed. The correct IANA registries are identified. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. N/A. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? N/A |
2021-05-26
|
05 | Ole Trøan | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed standard. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document describes how the Alternate Marking Method can be used as a passive performance measurement tool in an IPv6 domain. It defines a new Extension Header Option to encode alternate marking information in both the Hop-by-Hop Options Header and Destination Options Header. Working Group Summary: Nothing to note. Document Quality: **TBD Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? There is at least one commercial implementation of alternate marking for MPLS and SRv6. An implementation of this draft (alternative marking for HBH and DestOpt options) as a proof of concept is in progress. Personnel: Shepherd: Ole Troan AD: Erik Kline (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. Greg Mirsky and Brian Carpenter reviewed the document as part of the WG last call. The 6man chairs (including shepherd) reviewed the document in detail. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. Extension header option format reviewed by 6man. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Yes, there are two IPRs filed. No working group discussion has been had. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is good support among the interested individuals. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No nits found. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). IANA section has been reviewed. The correct IANA registries are identified. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. N/A. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? N/A |
2021-05-25
|
05 | Giuseppe Fioccola | New version available: draft-ietf-6man-ipv6-alt-mark-05.txt |
2021-05-25
|
05 | (System) | New version approved |
2021-05-25
|
05 | (System) | Request for posting confirmation emailed to previous authors: Fengwei Qin , Giuseppe Fioccola , Mauro Cociglio , Ran Pang , Tianran Zhou |
2021-05-25
|
05 | Giuseppe Fioccola | Uploaded new revision |
2021-05-21
|
04 | Ole Trøan | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed standard (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document describes how the Alternate Marking Method can be used as a passive performance measurement tool in an IPv6 domain. It defines a new Extension Header Option to encode alternate marking information in both the Hop-by-Hop Options Header and Destination Options Header. Working Group Summary: Nothing to note. Document Quality: ** Question asked to Giuseppe. Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Personnel: Shepherd: Ole Troan AD: Erik Kline (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. Greg Mirsky and Brian Carpenter reviewed the document as part of the WG last call. The 6man chairs (shepherd) reviewed the document in detail. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. Extension header option format reviewed by 6man. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? *** Awaiting response. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. Yes, there are two IPRs filed. No working group discussion has been had. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is good support among the interested individuals. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. *** awaiting resolution from authors. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. N/A (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). IANA section has been reviewed. The correct IANA registries are identified. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. N/A. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? N/A |
2021-05-21
|
04 | Ole Trøan | Notification list changed to bob.hinden@gmail.com, otroan@employees.org from bob.hinden@gmail.com because the document shepherd was set |
2021-05-21
|
04 | Ole Trøan | Document shepherd changed to Ole Trøan |
2021-03-08
|
04 | Giuseppe Fioccola | New version available: draft-ietf-6man-ipv6-alt-mark-04.txt |
2021-03-08
|
04 | (System) | New version approved |
2021-03-08
|
04 | (System) | Request for posting confirmation emailed to previous authors: Fengwei Qin , Giuseppe Fioccola , Mauro Cociglio , Ran Pang , Tianran Zhou |
2021-03-08
|
04 | Giuseppe Fioccola | Uploaded new revision |
2021-03-07
|
03 | Ole Trøan | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2021-03-07
|
03 | Ole Trøan | Added to session: IETF-110: 6man Thu-1700 |
2021-01-28
|
03 | Giuseppe Fioccola | New version available: draft-ietf-6man-ipv6-alt-mark-03.txt |
2021-01-28
|
03 | (System) | New version approved |
2021-01-28
|
03 | (System) | Request for posting confirmation emailed to previous authors: Fengwei Qin , Giuseppe Fioccola , Mauro Cociglio , Ran Pang , Tianran Zhou |
2021-01-28
|
03 | Giuseppe Fioccola | Uploaded new revision |
2021-01-18
|
02 | Ole Trøan | Notification list changed to bob.hinden@gmail.com because the document shepherd was set |
2021-01-18
|
02 | Ole Trøan | Document shepherd changed to Bob Hinden |
2021-01-18
|
02 | Ole Trøan | Changed consensus to Yes from Unknown |
2021-01-18
|
02 | Ole Trøan | Intended Status changed to Proposed Standard from None |
2020-10-13
|
02 | Giuseppe Fioccola | New version available: draft-ietf-6man-ipv6-alt-mark-02.txt |
2020-10-13
|
02 | (System) | New version approved |
2020-10-13
|
02 | (System) | Request for posting confirmation emailed to previous authors: Mauro Cociglio , Ran Pang , Giuseppe Fioccola , Fengwei Qin , Tianran Zhou |
2020-10-13
|
02 | Giuseppe Fioccola | Uploaded new revision |
2020-06-22
|
01 | Giuseppe Fioccola | New version available: draft-ietf-6man-ipv6-alt-mark-01.txt |
2020-06-22
|
01 | (System) | New version approved |
2020-06-22
|
01 | (System) | Request for posting confirmation emailed to previous authors: Fengwei Qin , Tianran Zhou , Mauro Cociglio , Giuseppe Fioccola , 6man-chairs@ietf.org |
2020-06-22
|
01 | Giuseppe Fioccola | Uploaded new revision |
2020-05-30
|
00 | Ole Trøan | This document now replaces draft-fz-6man-ipv6-alt-mark instead of None |
2020-05-30
|
00 | Giuseppe Fioccola | New version available: draft-ietf-6man-ipv6-alt-mark-00.txt |
2020-05-30
|
00 | (System) | WG -00 approved |
2020-05-30
|
00 | Giuseppe Fioccola | Set submitter to "Giuseppe Fioccola ", replaces to draft-fz-6man-ipv6-alt-mark and sent approval email to group chairs: 6man-chairs@ietf.org |
2020-05-30
|
00 | Giuseppe Fioccola | Uploaded new revision |