Skip to main content

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