Subject: [ippm] R: WGLC on draft-ietf-ippm-alt-mark

From: Fioccola Giuseppe <[email-masked]>
Date: Thu, 1 Jun 2017 08:19:00 +0000

Hi IPPMers,
First, I want to thank IPPM chairs for starting WGLC phase.
I think the document is stable and consolidated in terms of content and scope.
I support its publication (as co-author), also because there are related use cases, already presented within IETF, that need a reference document.

Best Regards,

Giuseppe

-----Messaggio originale-----
Da: ippm [mailto:[email-masked]] Per conto di Brian Trammell (IETF)
Inviato: martedì 30 maggio 2017 17:53
A: IETF IPPM WG
Oggetto: [ippm] WGLC on draft-ietf-ippm-alt-mark

Greetings, IPPM,

As discussed in Chicago, this message begins a Working Group Last Call on draft-ietf-ippm-alt-mark, to  to run until EOB CEST (UTC +2) Tuesday 20 June 2017. Please reply to [email-masked] indicating whether you believe this document is ready for publication, and if not, why not.

Many thanks, best regards,

Brian (as IPPM co-chair)

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. 

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. 

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: Alexander Clemm <[email-masked]>
Date: Thu, 1 Jun 2017 17:41:52 +0000

I think this is ready for publication. 

 I have only one very minor editorial nit regarding document structure:  There is a section 3.1.1 but no section 3.1.2.  I think it is preferable to have either at least two subsections, or none at all.  I understand that 3.1 is a long section that may require breaking up.  It seems that 3.1.1 could actually be elevated one level to become 3.2.  

Kind regards
--- Alex

-----Original Message-----
From: ippm [mailto:[email-masked]] On Behalf Of Fioccola Giuseppe
Sent: Thursday, June 01, 2017 1:19 AM
To: Brian Trammell (IETF) <[email-masked]>; IETF IPPM WG <[email-masked]>
Subject: [ippm] R: WGLC on draft-ietf-ippm-alt-mark

Hi IPPMers,

Best Regards,

Giuseppe

-----Messaggio originale-----
Da: ippm [mailto:[email-masked]] Per conto di Brian Trammell (IETF)
Inviato: martedì 30 maggio 2017 17:53
A: IETF IPPM WG
Oggetto: [ippm] WGLC on draft-ietf-ippm-alt-mark

Greetings, IPPM,

Brian (as IPPM co-chair)

_______________________________________________
ippm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ippm

---

From: Qin Wu <[email-masked]>
Date: Mon, 5 Jun 2017 01:24:34 +0000

I have re-read this document and believe it is ready for publication.
Here are a few minor comments as follows:
1. I feel disconnected when I read the last sentence of flow based strategy section:
"
      Another application
      is on Mobile Backhauling, implemented with a VPN MPLS in Telecom
      Italia's network; in this case the problem with unicast traffic is
      overcome by monitoring just the two Provider Edge nodes of the VPN
      MPLS.
"
How this is related to flow based case? How do you address load-balancing issue in Mobile backhauling case by monitoring two PEs nodes.
I suppose there are multiple hops between two PE nodes, I assume label entropy may be used to address load balancing issue.

2. As described in this draft, Traffic coloring can be implemented by setting a specific bit in the
 packet header and changing the value of that bit periodically. But it looks in this draft, traffic coloring is only supported by setting a specific bit of QoS related field such as DSCP field.
 Is this real intention or you can support other traffic color as well?
3.As described in this draft, two encodings of the DSCP field can be used to color the packets? What do you mean by two encoding, if my understanding is correct, you use one bit (bit 1) of the DSCP filed to color the packets, one bit (bit 0) to indicate flow under traffic monitoring.
 When bit 1 is set to 0, it corresponds to color A, when bit1 is set to 1, it corresponds to color B, Is bit1 set to 0 corresponding to one encoding while bit1 set to 1 corresponding to the other encoding?
4. Section 5.1.2 the 2nd paragraph
s/a couple od counters/a couple of counters

-Qin
-----邮件原件-----
发件人: ippm [mailto:[email-masked]] 代表 Brian Trammell (IETF)
发送时间: 2017年5月30日 23:53
收件人: IETF IPPM WG
主题: [ippm] WGLC on draft-ietf-ippm-alt-mark

Greetings, IPPM,

Brian (as IPPM co-chair)

---

From: Sudhin Jacob <[email-masked]>
Date: Mon, 5 Jun 2017 15:26:53 +0000

Hi All,

I support this draft. I think it is good for publication.

Regards,
Sudhin

-----Original Message-----
From: ippm [mailto:[email-masked]] On Behalf Of Alexander Clemm
Sent: Thursday, June 1, 2017 11:12 PM
To: Fioccola Giuseppe <[email-masked]>; Brian Trammell (IETF) <[email-masked]>; IETF IPPM WG <[email-masked]>
Subject: Re: [ippm] R: WGLC on draft-ietf-ippm-alt-mark

Kind regards
--- Alex

-----Original Message-----
From: ippm [mailto:[email-masked]] On Behalf Of Fioccola Giuseppe
Sent: Thursday, June 01, 2017 1:19 AM
To: Brian Trammell (IETF) <[email-masked]>; IETF IPPM WG <[email-masked]>
Subject: [ippm] R: WGLC on draft-ietf-ippm-alt-mark

Hi IPPMers,

Best Regards,

Giuseppe

-----Messaggio originale-----
Da: ippm [mailto:[email-masked]] Per conto di Brian Trammell (IETF)
Inviato: martedì 30 maggio 2017 17:53
A: IETF IPPM WG
Oggetto: [ippm] WGLC on draft-ietf-ippm-alt-mark

Greetings, IPPM,

Brian (as IPPM co-chair)

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 6 Jun 2017 07:39:07 +0000

I had a read through the draft, and can agree with the progress of draft-ietf-ippm-alt-mark 

Kind Regards,
G/

On 05/06/2017, 17:26, "ippm on behalf of Sudhin Jacob" <[email-masked] on behalf of [email-masked]> wrote:

    Hi All,

    Regards,
    Sudhin
    
    -----Original Message-----
    From: ippm [mailto:[email-masked]] On Behalf Of Alexander Clemm
    Sent: Thursday, June 1, 2017 11:12 PM
    To: Fioccola Giuseppe <[email-masked]>; Brian Trammell (IETF) <[email-masked]>; IETF IPPM WG <[email-masked]>
    Subject: Re: [ippm] R: WGLC on draft-ietf-ippm-alt-mark

    
    Kind regards
    --- Alex
    
    -----Original Message-----
    From: ippm [mailto:[email-masked]] On Behalf Of Fioccola Giuseppe
    Sent: Thursday, June 01, 2017 1:19 AM
    To: Brian Trammell (IETF) <[email-masked]>; IETF IPPM WG <[email-masked]>
    Subject: [ippm] R: WGLC on draft-ietf-ippm-alt-mark
    
    Hi IPPMers,
    
    Best Regards,
    
    Giuseppe
    
    -----Messaggio originale-----
    Da: ippm [mailto:[email-masked]] Per conto di Brian Trammell (IETF)
    Inviato: martedì 30 maggio 2017 17:53
    A: IETF IPPM WG
    Oggetto: [ippm] WGLC on draft-ietf-ippm-alt-mark
    
    Greetings, IPPM,

    
    Brian (as IPPM co-chair)

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 6 Jun 2017 07:59:01 -0700

Hi Brian, WG community,
I believe that the document is ready for publication. The Alternate Marking
method is useful and mature technology to measure performance metrics.
Several WGs in the Routing Area are working on adapting the Alternate
Marking method as passive PM OAM.
As co-author I'm committed to work on it and address all the comments
throughout the publication process.

Regards,
Greg

On Tue, May 30, 2017 at 8:53 AM, Brian Trammell (IETF) <[email-masked]>
wrote:

> Greetings, IPPM,
>
> As discussed in Chicago, this message begins a Working Group Last Call on
> draft-ietf-ippm-alt-mark, to  to run until EOB CEST (UTC +2) Tuesday 20
> June 2017. Please reply to [email-masked] indicating whether you believe
> this document is ready for publication, and if not, why not.
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 6 Jun 2017 17:03:05 +0000

Brian,

I support advancing this document and believe it’s ready to be sent to the IESG.

This is an important document and foundation to specific protocol realizations, and its quality is very good. I also believe that Experimental, as currently intended, is appropriate.

I do have a set of comments, for consideration as part of this WGLC.

While the method itself is described in great detail and with care, some contextual information and text around justifications or potential future implementation is a bit more loose.

Comments:

A. Title and method

The title of this document is “Alternate Marking method for passive performance monitoring”.

However, as Greg Mirsky repeatedly mentioned in different contexts, let’s use IETF definitions or active/passive/inband/etc. As such, Passive monitoring does not modify packets.

Based on the definition at RFC 7799 (which is not referenced):

https://tools.ietf.org/html/rfc7799#section-3.6
3.6.  Passive Methods

   Passive Methods of Measurement are:

   o  based solely on observations of an undisturbed and unmodified
      packet stream of interest (in other words, the method of
      measurement MUST NOT add, change, or remove packets or fields or
      change field values anywhere along the path).

Saying “marking for passive” is, based on this definition, an oxymoron. Marking / coloring would go against the definition of passive.

B. Specific comments:

1.  Introduction

   Nowadays, most of the traffic in Service Providers' networks carries
   real time content.

CMP: While I do not dispute that statement, a citation would not hurt to support the definitiveness of the very first sentence setting the tone for the whole document.

CMP: Sections 2-4 look great.

CMP: I think there are issues in Section 5. Section 5 should cover the following:

   o  Section 5 reports examples of implementation and deployment of the
      method.  Furthermore the operational experiment done at Telecom
      Italia is described;

CMP: And Section 5.1 is perfect and describes exactly the example of implementation. However:

5.3.  Performance Measurement Marking Method in BIER Domain

CMP: The draft inherently describes a unicast service, not sure if this document is not scoped to claim this sub-section.

5.4.  Overlay OAM Passive Performance Measurement

   The Overlay OAM Design Team is considering the preliminary OAM
   requirements from NVO3, BIER, and SFC.  Marking Method is the
   preferred passive method to measure performance.

   [I-D.ooamdt-rtgwg-ooam-requirement] and
   [I-D.ooamdt-rtgwg-oam-gap-analysis] explain in deep this item.

CMP: This to me is a gross extrapolation. The text as written is simply incorrect, and there’s no maturity or broad alignment to include this I recommend removing this whole Section 5.4.
CMP: This is neither “examples of implementation or deployment”.

Net-net, I support this document but recommend these comments are addressed.

Thanks,

— Carlos.

> On May 30, 2017, at 11:53 AM, Brian Trammell (IETF) <[email-masked]> wrote:
> 
> Greetings, IPPM,
>

---

From: Fioccola Giuseppe <[email-masked]>
Date: Wed, 7 Jun 2017 15:17:34 +0000

Thank you, Alex. It makes sense, section 3.1.1 could be elevated to become 3.2.
I will address this editorial change.

Giuseppe

-----Messaggio originale-----
Da: Alexander Clemm [mailto:[email-masked]] 
Inviato: giovedì 1 giugno 2017 19:42
A: Fioccola Giuseppe; Brian Trammell (IETF); IETF IPPM WG
Oggetto: RE: [ippm] R: WGLC on draft-ietf-ippm-alt-mark

Kind regards
--- Alex

-----Original Message-----
From: ippm [mailto:[email-masked]] On Behalf Of Fioccola Giuseppe
Sent: Thursday, June 01, 2017 1:19 AM
To: Brian Trammell (IETF) <[email-masked]>; IETF IPPM WG <[email-masked]>
Subject: [ippm] R: WGLC on draft-ietf-ippm-alt-mark

Hi IPPMers,

Best Regards,

Giuseppe

-----Messaggio originale-----
Da: ippm [mailto:[email-masked]] Per conto di Brian Trammell (IETF)
Inviato: martedì 30 maggio 2017 17:53
A: IETF IPPM WG
Oggetto: [ippm] WGLC on draft-ietf-ippm-alt-mark

Greetings, IPPM,

Brian (as IPPM co-chair)

---

From: Fioccola Giuseppe <[email-masked]>
Date: Wed, 7 Jun 2017 15:44:38 +0000

Qin, Thanks for your support.
Answers inline tagged as [GF].

Giuseppe

-----Messaggio originale-----
Da: Qin Wu [mailto:[email-masked]] 
Inviato: lunedì 5 giugno 2017 03:25
A: Brian Trammell (IETF); IETF IPPM WG
Cc: Fioccola Giuseppe
Oggetto: RE: [ippm] WGLC on draft-ietf-ippm-alt-mark

[GF]: This specific implementation is not detailed so much here because is out of scope, but it is performed on each flow between two or more PEs and not in the MPLS cloud. The flows are identified and filtered by using source and destination IP addresses. In the middle there is no way to make deep packet inspection to count the marked DSCP field and the monitoring should be done by using RFC6374 SFL. In case of load-balancing we are in a multipoint situation and it is possible to couple the counters.

2. As described in this draft, Traffic coloring can be implemented by setting a specific bit in the  packet header and changing the value of that bit periodically. But it looks in this draft, traffic coloring is only supported by setting a specific bit of QoS related field such as DSCP field.
 Is this real intention or you can support other traffic color as well?

[GF]: The DSCP marking field is just an example. We used this field only because the current router capabilities enable to mark and count based on DSCP field in a simple way. Section 5.2, 5.3, 5.4, 5.5, 5.6 describe the existing Use Cases, for example in BIER you have two dedicated and reserved bits for marking method.

[GF]: Yes, but this is just a description of the experiment in TI network. For instance in IPFPM the "evil bit" is proposed for marking.

[GF]: ok

-Qin
-----邮件原件-----
发件人: ippm [mailto:[email-masked]] 代表 Brian Trammell (IETF)
发送时间: 2017年5月30日 23:53
收件人: IETF IPPM WG
主题: [ippm] WGLC on draft-ietf-ippm-alt-mark

Greetings, IPPM,

Brian (as IPPM co-chair)

Rispetta l'ambiente. Non stampare questa mail se non � necessario.

---

From: Fioccola Giuseppe <[email-masked]>
Date: Wed, 7 Jun 2017 16:11:38 +0000

Thanks for the support, Carlos.
Answers to your comments are inline tagged as [GF].

Giuseppe

-----Messaggio originale-----
Da: ippm [mailto:[email-masked]] Per conto di Carlos Pignataro (cpignata)
Inviato: martedì 6 giugno 2017 19:03
A: Brian Trammell (IETF)
Cc: IETF IPPM WG
Oggetto: Re: [ippm] WGLC on draft-ietf-ippm-alt-mark

Brian,

Comments:

A. Title and method

[GF]: Agree, this is an important point we should clarify together with IPPM. A reference to RFC7799 can be added. In my opinion, marking method could be considered hybrid or passive depending on the case. In case the marking bits are part of the DSCP field (as an example) the technique is hybrid. In case the marking bits are dedicated and reserved and are included in the protocol specification (e.g. BIER) marking technique can be considered as passive. I suggest to add also hybrid in the title.

B. Specific comments:

1.  Introduction

[GF]: Agree, we can extend this statement.

[GF]: Here is an example on how to use this method as passive.

[GF]: Yes, this is inherited by old versions of the document. It will be deleted or rephrased.

Thanks,

— Carlos.

---

From: Carlos Pignataro <[email-masked]>
Date: Wed, 7 Jun 2017 12:52:18 -0400

Ciao, Giuseppe,

Happy to support this document.

I agree with all your responses. Please find a couple followups inline.

> On Jun 7, 2017, at 12:11 PM, Fioccola Giuseppe <[email-masked]> wrote:
> 

CMP: I agree with you overall. I believe a very small new subsection within the Introduction, speaking to the categorization, as well as a potential title update will address this comment. 

CMP: And I would like to understand from IPPM whether setting or clearing pre-allocated bits is really passive (since RFC 7799 says “ MUST NOT change field values” for Passive.)

> [GF]: Yes, this is inherited by old versions of the document. It will be deleted or rephrased.

CMP: I would recommend deleting it as it appears old noise.

Thanks,

Carlos.

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 7 Jun 2017 13:34:24 -0700

Hi Carlos,
RFC 7799 acknowledges that with proper instrumentation methods that modify
data packets may produce measurement results as passive measurement methods:

   There may be circumstances where results measured with Hybrid Methods
   can be considered equivalent to those measured with Passive Methods.

In that sense the Alternate Marking method may be applied so that is
behaves and produces results as passive measurement method.

Regards,
Greg

On Wed, Jun 7, 2017 at 9:52 AM, Carlos Pignataro <[email-masked]> wrote:

> > This is an important document and foundation to specific protocol
> realizations, and its quality is very good. I also believe that
> Experimental, as currently intended, is appropriate.
> >
> > While the method itself is described in great detail and with care, some
> contextual information and text around justifications or potential future
> implementation is a bit more loose.
> >
> > Comments:
> >
> > A. Title and method
> >
> > However, as Greg Mirsky repeatedly mentioned in different contexts,
> let’s use IETF definitions or active/passive/inband/etc. As such, Passive
> monitoring does not modify packets.
> >
> > Saying “marking for passive” is, based on this definition, an oxymoron.
> Marking / coloring would go against the definition of passive.
> >
> > [GF]: Agree, this is an important point we should clarify together with
> IPPM. A reference to RFC7799 can be added. In my opinion, marking method
> could be considered hybrid or passive depending on the case. In case the
> marking bits are part of the DSCP field (as an example) the technique is
> hybrid. In case the marking bits are dedicated and reserved and are
> included in the protocol specification (e.g. BIER) marking technique can be
> considered as passive. I suggest to add also hybrid in the title.
>
> CMP: I agree with you overall. I believe a very small new subsection
> within the Introduction, speaking to the categorization, as well as a
> potential title update will address this comment.
>
> CMP: And I would like to understand from IPPM whether setting or clearing
> pre-allocated bits is really passive (since RFC 7799 says “ MUST NOT change
> field values” for Passive.)
>
> >
> > B. Specific comments:
> >
> > 1.  Introduction
> >
> > CMP: While I do not dispute that statement, a citation would not hurt to
> support the definitiveness of the very first sentence setting the tone for
> the whole document.
> >
> > CMP: The draft inherently describes a unicast service, not sure if this
> document is not scoped to claim this sub-section.
> >
> > CMP: This to me is a gross extrapolation. The text as written is simply
> incorrect, and there’s no maturity or broad alignment to include this I
> recommend removing this whole Section 5.4.
> >> As discussed in Chicago, this message begins a Working Group Last Call
> on draft-ietf-ippm-alt-mark, to  to run until EOB CEST (UTC +2) Tuesday 20
> > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
> persone indicate. La diffusione, copia o qualsiasi altra azione derivante
> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora
> abbiate ricevuto questo documento per errore siete cortesemente pregati di
> darne immediata comunicazione al mittente e di provvedere alla sua
> distruzione, Grazie.
> >
> > This e-mail and any attachments is confidential and may contain
> privileged information intended for the addressee(s) only. Dissemination,
> copying, printing or use by anybody else is unauthorised. If you are not
> the intended recipient, please delete this message and any attachments and
> advise the sender by return e-mail, Thanks.
> >

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 7 Jun 2017 21:02:30 +0000

Greg,

Thank you for the follow-up.

What you write is very interesting but irrelevant and orthogonal to my comment. I am not commenting on equivalency of results. I am commenting on naming and definition of terms. I think Giuseppe’s response was more useful:
> [GF]: Agree, this is an important point we should clarify together with IPPM.

Thank you for initially pointing to the definitions in RFC 7799. Indeed, under some circumstances, passive and hybrid can produce equivalent results.
However, under all circumstances, hybrid *is* hybrid, and passive is, well, passive.

Yes, results can be considered equivalent (under some circumstances). No, we cannot rename things. No, equivalent results does not mean re-categorization.

Given the fact that there are open questions (such as, what happens from a definition perspective if there is Marking for fields that are actually reserved for this functionality as opposed to overloading fields), I recommend a small subsection of the Intro explaining the proper categorization.

And given the fact that the first bullet in the definition at https://tools.ietf.org/html/rfc7799#section-3.6 includes "undisturbed and unmodified” and "MUST NOT […] change field values” which is quite unequivocal of a statement.

Best,

— Carlos.

On Jun 7, 2017, at 4:34 PM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,
RFC 7799 acknowledges that with proper instrumentation methods that modify data packets may produce measurement results as passive measurement methods:

In that sense the Alternate Marking method may be applied so that is behaves and produces results as passive measurement method.

Regards,
Greg

On Wed, Jun 7, 2017 at 9:52 AM, Carlos Pignataro <[email-masked]<mailto:[email-masked]>> wrote:
Ciao, Giuseppe,

> On Jun 7, 2017, at 12:11 PM, Fioccola Giuseppe <[email-masked]<mailto:[email-masked]>> wrote:
>
> Da: ippm [mailto:[email-masked]<mailto:[email-masked]>] Per conto di Carlos Pignataro (cpignata)

Thanks,

Carlos.

>> On May 30, 2017, at 11:53 AM, Brian Trammell (IETF) <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> Greetings, IPPM,
>>
>> As discussed in Chicago, this message begins a Working Group Last Call on draft-ietf-ippm-alt-mark, to  to run until EOB CEST (UTC +2) Tuesday 20 June 2017. Please reply to [email-masked]<mailto:[email-masked]> indicating whether you believe this document is ready for publication, and if not, why not.
>>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ippm

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 7 Jun 2017 14:16:53 -0700

Hi Carlos,
I'm not against clarification that would refer to the Alternate Marking
method as Hybrid per RFC 7799 that can be applied to a network in the
manner so it behaves and produces results as Passive method. Hope such
clarification would address your concern.

Regards,
Greg

On Wed, Jun 7, 2017 at 2:02 PM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> What you write is very interesting but irrelevant and orthogonal to my
> comment. I am not commenting on equivalency of results. I am commenting on
> naming and definition of terms. I think Giuseppe’s response was more useful:
> IPPM.
> Thank you for initially pointing to the definitions in RFC 7799. Indeed,
> under some circumstances, passive and hybrid can produce equivalent
> results.
> Yes, results can be considered equivalent (under some circumstances). No,
> we cannot rename things. No, equivalent results does not mean
> re-categorization.
>
> Given the fact that there are open questions (such as, what happens from a
> definition perspective if there is Marking for fields that are actually
> reserved for this functionality as opposed to overloading fields), I
> recommend a small subsection of the Intro explaining the proper
> categorization.
>
> And given the fact that the first bullet in the definition at
> https://tools.ietf.org/html/rfc7799#section-3.6 includes "undisturbed and
> unmodified” and "MUST NOT […] change field values” which is quite
> unequivocal of a statement.
>
> Best,
>
> — Carlos.
>
> On Jun 7, 2017, at 4:34 PM, Greg Mirsky <[email-masked]> wrote:
>
> Hi Carlos,
>> > On Jun 7, 2017, at 12:11 PM, Fioccola Giuseppe <
>> [email-masked]> wrote:
>> >
>> > While the method itself is described in great detail and with care,
>> some contextual information and text around justifications or potential
>> future implementation is a bit more loose.
>> >
>> > Comments:
>> >
>> > A. Title and method
>> >
>> > CMP: While I do not dispute that statement, a citation would not hurt
>> to support the definitiveness of the very first sentence setting the tone
>> for the whole document.
>> >

---

From: Praveen Ananthasankaran <[email-masked]>
Date: Fri, 09 Jun 2017 10:13:55 +0000

Hi All,

I believe the document is ready for publication.
Its a useful technology for performance metrics measurement.

Thanks,
Praveen

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Sun, 11 Jun 2017 13:46:52 +0000

Hi  Brian,
    
    I support WGLC of the document .
    
    I have some comments, for consideration as part of this WGLC. 

    The language needs to be tightened up, I would hope the GEN-ART review would take care of that. 

     Is coloring or marking  of a packet considered active of passive ? 

   During a  block 1, 3, …, n+1  should be  1, 3, …, 2n+1   

   during a B block (blocks 2, 4 and n)  should be    2, 4, …, 2n

Thanks
Mouli

---

From: Fioccola Giuseppe <[email-masked]>
Date: Mon, 12 Jun 2017 12:55:03 +0000

Hi Mouli, All
Thanks for the support.
My answers inline tagged as [GF].

Giuseppe

-----Messaggio originale-----
Da: ippm [mailto:[email-masked]] Per conto di Mouli Chandramouli (moulchan)
Inviato: domenica 11 giugno 2017 15:47
A: IETF IPPM WG; Brian Trammell (IETF)
Oggetto: Re: [ippm] WGLC on draft-ietf-ippm-alt-mark

    Hi  Brian,

[GF]: A small new subsection and a reference to RFC7799 will be added within the Introduction. In addition, if IPPM agree, the categorization of marking method will be detailed: it can be considered hybrid or passive depending on the case (bits dedicated or not).

[GF]: Ok, It will be fixed.

Thanks
Mouli

---

From: Cociglio Mauro <[email-masked]>
Date: Mon, 12 Jun 2017 15:26:28 +0000

Hi All,
I support the publication as coauthor.
Regards.
Mauro

-----Messaggio originale-----
Da: ippm [mailto:[email-masked]] Per conto di Brian Trammell (IETF)
Inviato: martedì 30 maggio 2017 17:53
A: IETF IPPM WG
Oggetto: [ippm] WGLC on draft-ietf-ippm-alt-mark

Greetings, IPPM,

Brian (as IPPM co-chair)

---

From: "J. Ignacio Alvarez-Hamelin" <[email-masked]>
Date: Mon, 12 Jun 2017 12:41:17 -0300 (ART)

Dear all,

I support this work. I consider that is a clever way to make measurements.

My brief comments:

1) We still need some synchronization support which is hard for 
iter-domain proposes.

2) I still not convinced about the "central role" give to the mean delay. 
Giving more importance to quantiles is more accurate because of the heavy 
tails is traffic and its delays.

Best,

 	Ignacio

_______________________________________________________________

Dr. Ing. José Ignacio Alvarez-Hamelin
CONICET and Facultad de Ingeniería, Universidad de Buenos Aires
Av. Paseo Colón 850 - C1063ACV - Buenos Aires - Argentina
+54 (11) 5285 0716 / 5285 0705
e-mail: [email-masked]
web: http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/
_______________________________________________________________

---

From: Fioccola Giuseppe <[email-masked]>
Date: Mon, 12 Jun 2017 16:28:20 +0000

Hi José Ignacio,
Thanks for your support and comments, my answers inline tagged as [GF]

Giuseppe

-----Messaggio originale-----
Da: ippm [mailto:[email-masked]] Per conto di J. Ignacio Alvarez-Hamelin
Inviato: lunedì 12 giugno 2017 17:41
A: IETF IPPM WG; Brian Trammell (IETF)
Oggetto: Re: [ippm] WGLC on draft-ietf-ippm-alt-mark

Dear all,

My brief comments:

1) We still need some synchronization support which is hard for iter-domain proposes.

2) I still not convinced about the "central role" give to the mean delay. 
Giving more importance to quantiles is more accurate because of the heavy tails is traffic and its delays.

[GF]: Mean Delay is now just an option (subsection) of the single marking method. I will try to deemphasize a little bit more.

Best,

 	Ignacio

CONICET and Facultad de Ingeniería, Universidad de Buenos Aires Av. Paseo Colón 850 - C1063ACV - Buenos Aires - Argentina

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Tue, 20 Jun 2017 17:52:08 +0200

This WGLC is concluded. The authors will submit a new version, addressing WGLC comments, and this version will be submitted to the IESG for publication.

Many thanks to the authors, and to the reviewers for their feedback,

Cheers,

Brian (as IPPM co-chair)

> Begin forwarded message:
> 
> From: "Brian Trammell (IETF)" <[email-masked]>
> Subject: WGLC on draft-ietf-ippm-alt-mark
> Date: 30 May 2017 at 17:53:26 GMT+2
> To: IETF IPPM WG <[email-masked]>
> 
> Greetings, IPPM,
>