Subject: [ippm] FW: New Version Notification for draft-fioccola-ippm-multipoint-alt-mark-03.txt

From: Fioccola Giuseppe <[email-masked]>
Date: Mon, 4 Jun 2018 15:32:05 +0000

Hi All,
This new version of the draft addresses the comments received during the last few weeks.
I want to thank Qin, Tal and Rachel for their fruitful inputs that have helped to improve the document structure.
This new revision includes a better description of:
- the scope of multipoint alternate marking with respect to the base alternate marking approach (RFC8321),
- the algorithm for Cluster partition with a step-by-step example,
- the delay measurement methods applicable for multipoint paths,
- the classification between multipoint paths basis and single packet basis delay measurement.

Would appreciate additional feedbacks.

Best Regards,

Giuseppe

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: lunedì 4 giugno 2018 17:05
To: Riccardo Sisto <[email-masked]>; Fioccola Giuseppe <[email-masked]>; Cociglio Mauro <[email-masked]>; Amedeo Sapio <[email-masked]>
Subject: New Version Notification for draft-fioccola-ippm-multipoint-alt-mark-03.txt

A new version of I-D, draft-fioccola-ippm-multipoint-alt-mark-03.txt
has been successfully submitted by Giuseppe Fioccola and posted to the IETF repository.

Name:		draft-fioccola-ippm-multipoint-alt-mark
Revision:	03
Title:		Multipoint Alternate Marking method for passive and hybrid performance monitoring
Document date:	2018-06-04
Group:		Individual Submission
Pages:		18
URL:            https://www.ietf.org/internet-drafts/draft-fioccola-ippm-multipoint-alt-mark-03.txt
Status:         https://datatracker.ietf.org/doc/draft-fioccola-ippm-multipoint-alt-mark/
Htmlized:       https://tools.ietf.org/html/draft-fioccola-ippm-multipoint-alt-mark-03
Htmlized:       https://datatracker.ietf.org/doc/html/draft-fioccola-ippm-multipoint-alt-mark
Diff:           https://www.ietf.org/rfcdiff?url2=draft-fioccola-ippm-multipoint-alt-mark-03

Abstract:
   The Alternate Marking method, as presented in RFC 8321 [RFC8321], can
   be applied only to point-to-point flows because it assumes that all
   the packets of the flow measured on one node are measured again by a
   single second node.  This document aims to generalize and expand this
   methodology to measure any kind of unicast flows, whose packets can
   follow several different paths in the network, in wider terms a
   multipoint-to-multipoint network.  For this reason the technique here
   described is called Multipoint Alternate Marking.  Some definitions
   here introduced extend the scope of RFC 5644 [RFC5644] in the context
   of alternate marking schema.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Tue, 12 Jun 2018 01:26:11 +0000

Hi Guiseppi,

I have read through much of your draft,
and I have a question about the measurement interval
of the various multi* to multi* measurements.

For example, consider the multipoint diagram below.
It should be possible to synchronize clocks, and the beginning of
the measurement interval at R1 and R2 and R3 to some degree
(but more about this later).
Also, your point-to-point RFC8321 has the ability to
synchronize measurements along the single point-to-point 
path. If we consider the R1>R4>R6 path, there are three 
intervals of time, T(R1), T(R4), T(R6) where loss is 
measured, and they look something like this:

time -> start         stop
T(R1)   |-------------|
T(R4)     |-------------|
T(R6)        |-------------|

The IPPM Active metric of Loss would indicate that T(R1) is
the measurement interval for describing the results,
so it would be good to note this.

          multipoint-to-multipoint
              +------+                +------+
          ---<>  R1  <>              <>  R6  <>---
              +------+ \            / +------+
                        \ +------+ /
                         <>  R4  <>
                          +------+ \
              +------+              \ +------+
          ---<>  R2  <>             <>  R7  <>---
              +------+ \            / +------+
                        \ +------+ /
                         <>  R5  <>
                        / +------+ \
              +------+ /            \ +------+
          ---<>  R3  <>              <>  R8  <>---
              +------+                +------+

                       Figure 1: Flow classification
					   
When we expand to multipoint-to-multipoint flows, we have a more
complicated case when specifying the true measurement interval.
For example, at the source routers, the 3 source measurement intervals: 

T(R1)   |-------------|
T(R2)   |---------------|  <- is it possible some intervals to be longer?
T(R3)   |-------------|

...due to characteristics of the selected flows (where there may be
time gaps between packets in a selected flow)? 

Or, due to flow characteristics, is it possible that the 
measured intervals take-on some stagger in time?

T(R1)   |-------------|
T(R2)    |-------------|
T(R3)     |-------------|

Either of the two cases above represent some challenge when accurately
describing the measurement interval, and when comparing the results of
this method with Active measurements where the source is R1,2, or 3.

Are these cases possible? Maybe I missed something.

regards,
Al

> From: ippm [mailto:[email-masked]] On Behalf Of Fioccola Giuseppe
> Sent: Monday, June 4, 2018 11:32 AM
> To: [email-masked]
> Cc: [email-masked]; 'draft-fioccola-ippm-multipoint-alt-
> [email-masked]' <[email-masked]>; Tal
> Mizrahi ([email-masked]) <[email-masked]>
> Subject: [ippm] FW: New Version Notification for draft-fioccola-ippm-
> multipoint-alt-mark-03.txt
> 
> Hi All,
> 
> I want to thank Qin, Tal and Rachel for their fruitful inputs that have
> helped to improve the document structure.
> 
> To: Riccardo Sisto <[email-masked]>; Fioccola Giuseppe
> <[email-masked]>; Cociglio Mauro
> <[email-masked]>; Amedeo Sapio <[email-masked]>
> 
> URL:            https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_internet-2Ddrafts_draft-2Dfioccola-2Dippm-2Dmultipoint-
> 2Dalt-2Dmark-2D03.txt&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=fiShY_CVpXGJ7HSXBG36auVFJUMZZ
> 6QXshKyKQh38t0&s=Ov3bjWioq6hd0DtGHBFLUFbdPxfS7XEStRpuoWePFK4&e=
> 
> Status:         https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dfioccola-2Dippm-2Dmultipoint-2Dalt-
> 2Dmark_&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=fiShY_CVpXGJ7HSXBG36auVFJUMZZ
> 6QXshKyKQh38t0&s=FBSs4ss-Pb__2CLgrtlbtdJwv6HaNBG7l8iWEPLrg5Q&e=
> 
> Htmlized:       https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_draft-2Dfioccola-2Dippm-2Dmultipoint-2Dalt-2Dmark-
> 2D03&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=fiShY_CVpXGJ7HSXBG36auVFJUMZZ
> 6QXshKyKQh38t0&s=gWtNlAO9RJ57xWpStxqyN50T43nxPAj6649qoXGZyGY&e=
> 
> Htmlized:       https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_html_draft-2Dfioccola-2Dippm-2Dmultipoint-
> 2Dalt-2Dmark&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=fiShY_CVpXGJ7HSXBG36auVFJUMZZ
> 6QXshKyKQh38t0&s=ZH4B6o-mLdrfE6u1wJqQucMoOEjgqqjfnVlIzNk9SJ8&e=
> 
> Diff:           https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dfioccola-2Dippm-2Dmultipoint-
> 2Dalt-2Dmark-2D03&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=fiShY_CVpXGJ7HSXBG36auVFJUMZZ
> 6QXshKyKQh38t0&s=v4Z4vF7ps9L1rbfpE69_tEh1SSe7NfaKypXQyqlkUyA&e=
> 
> 
> 
> Abstract:
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> 
> 
> 
> The IETF Secretariat
> 
> 
> 
> 
> 
> 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.
> 
> 
> 
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ippm&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=fiShY_CVpXGJ7HSXBG36auVFJUMZZ
> 6QXshKyKQh38t0&s=CYN4YVm6s2iUa2LyyND9eQ1xR-BdB8F5XvE2DV6Q55M&e=

---

From: Fioccola Giuseppe <[email-masked]>
Date: Tue, 12 Jun 2018 14:28:30 +0000

Hi Al,
Thanks for your fruitful feedback.
This is a very good point and I think we need a dedicated Section (as for RFC8321) to detail.
I will certainly add a note on the correlation with Active Loss metric and T(R1) is the measurement interval for describing the results for multipoint alternate marking too.
Both cases you have pointed out are possible.
As you have mentioned, RFC8321 explains this concept for point-to-point flow in Section 3.2 "Timing Aspects", but the same issue must be generalized for multipoint-to multipoint network.
The 3 source routers mark the traffic and, in general, the 3 source measurement intervals can be of different lengths and with different offsets.
Consider the following figure:

   ...BBBBBBBBB | AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA| BBBBBBBBB...
                             |<======================================>|
                             |                                          L                                            |
   ...=========>|<==================><==================>|<==========...
                             |                 L/2                                          L/2                 |
                             |<===>|                                                             |<===>| 
                                    d   |                                                              |   d
                                         |<==========================>|
                                                 available counting interval

The total contribution of this mismatch between the marking source routers gives an additional constraint and this value can be added to d (that already includes clock error and network delay). 
However, in summary, the condition to be satisfied, for each measurement point on the multipoint path, is that the available counting interval must be > 0.
I will add these considerations in a new Section of the next revision. What do you think?

Best Regards,

Giuseppe

-----Original Message-----
From: MORTON, ALFRED C (AL) [mailto:[email-masked]] 
Sent: martedì 12 giugno 2018 03:26
To: Fioccola Giuseppe <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]' <[email-masked]>; Tal Mizrahi ([email-masked]) <[email-masked]>
Subject: RE: New Version Notification for draft-fioccola-ippm-multipoint-alt-mark-03.txt

Hi Guiseppi,

I have read through much of your draft,
and I have a question about the measurement interval of the various multi* to multi* measurements.

For example, consider the multipoint diagram below.
It should be possible to synchronize clocks, and the beginning of the measurement interval at R1 and R2 and R3 to some degree (but more about this later).
Also, your point-to-point RFC8321 has the ability to synchronize measurements along the single point-to-point path. If we consider the R1>R4>R6 path, there are three intervals of time, T(R1), T(R4), T(R6) where loss is measured, and they look something like this:

time -> start         stop
T(R1)   |-------------|
T(R4)     |-------------|
T(R6)        |-------------|

The IPPM Active metric of Loss would indicate that T(R1) is the measurement interval for describing the results, so it would be good to note this.

          multipoint-to-multipoint
              +------+                +------+
          ---<>  R1  <>              <>  R6  <>---
              +------+ \            / +------+
                        \ +------+ /
                         <>  R4  <>
                          +------+ \
              +------+              \ +------+
          ---<>  R2  <>             <>  R7  <>---
              +------+ \            / +------+
                        \ +------+ /
                         <>  R5  <>
                        / +------+ \
              +------+ /            \ +------+
          ---<>  R3  <>              <>  R8  <>---
              +------+                +------+

When we expand to multipoint-to-multipoint flows, we have a more complicated case when specifying the true measurement interval.
For example, at the source routers, the 3 source measurement intervals: 

T(R1)   |-------------|

...due to characteristics of the selected flows (where there may be time gaps between packets in a selected flow)? 

Or, due to flow characteristics, is it possible that the measured intervals take-on some stagger in time?

T(R1)   |-------------|
T(R2)    |-------------|
T(R3)     |-------------|

Either of the two cases above represent some challenge when accurately describing the measurement interval, and when comparing the results of this method with Active measurements where the source is R1,2, or 3.

regards,
Al

> I want to thank Qin, Tal and Rachel for their fruitful inputs that 
> have helped to improve the document structure.
> 
> Subject: New Version Notification for 
> draft-fioccola-ippm-multipoint-alt-
> mark-03.txt
> 
> 
> 
> 
> 
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=fiShY_CVpXGJ7HSXBG36auVFJ
> UMZZ 6QXshKyKQh38t0&s=Ov3bjWioq6hd0DtGHBFLUFbdPxfS7XEStRpuoWePFK4&e=
> 
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=fiShY_CVpXGJ7HSXBG36auVFJ
> UMZZ 6QXshKyKQh38t0&s=FBSs4ss-Pb__2CLgrtlbtdJwv6HaNBG7l8iWEPLrg5Q&e=
> 
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=fiShY_CVpXGJ7HSXBG36auVFJ
> UMZZ 6QXshKyKQh38t0&s=gWtNlAO9RJ57xWpStxqyN50T43nxPAj6649qoXGZyGY&e=
> 
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=fiShY_CVpXGJ7HSXBG36auVFJ
> UMZZ 6QXshKyKQh38t0&s=ZH4B6o-mLdrfE6u1wJqQucMoOEjgqqjfnVlIzNk9SJ8&e=
> 
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=fiShY_CVpXGJ7HSXBG36auVFJ
> UMZZ 6QXshKyKQh38t0&s=v4Z4vF7ps9L1rbfpE69_tEh1SSe7NfaKypXQyqlkUyA&e=
> 
> 
> 
> Abstract:
> 
> 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.
> 
> 
> 
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=fiShY_CVpXGJ7HSXBG36auVFJ
> UMZZ 6QXshKyKQh38t0&s=CYN4YVm6s2iUa2LyyND9eQ1xR-BdB8F5XvE2DV6Q55M&e=

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Tue, 12 Jun 2018 16:39:10 +0000

Hi Giuseppe,
Thanks for your reply and agreement on this issue.

I think a CR-removing application made a mess of your figure, below,
despite our use of plain text.

I'll be better able to say what I think of your proposal 
for a new section after seeing all the info you kindly 
provided.  :-)

Al

> From: Fioccola Giuseppe [mailto:[email-masked]]
> Sent: Tuesday, June 12, 2018 10:29 AM
> To: MORTON, ALFRED C (AL) <[email-masked]>; [email-masked]
> I will certainly add a note on the correlation with Active Loss metric and
> T(R1) is the measurement interval for describing the results for
> multipoint alternate marking too.
> As you have mentioned, RFC8321 explains this concept for point-to-point
> flow in Section 3.2 "Timing Aspects", but the same issue must be
> generalized for multipoint-to multipoint network.
> The 3 source routers mark the traffic and, in general, the 3 source
> measurement intervals can be of different lengths and with different
> offsets.
>                              |                                          L
> |
>                              |                 L/2
> L/2                 |
>                              |<===>|
> |<===>|
>                                     d   |
> |   d
> The total contribution of this mismatch between the marking source routers
> gives an additional constraint and this value can be added to d (that
> already includes clock error and network delay).
> However, in summary, the condition to be satisfied, for each measurement
> point on the multipoint path, is that the available counting interval must
> be > 0.
> It should be possible to synchronize clocks, and the beginning of the
> measurement interval at R1 and R2 and R3 to some degree (but more about
> this later).
> Also, your point-to-point RFC8321 has the ability to synchronize
> measurements along the single point-to-point path. If we consider the
> R1>R4>R6 path, there are three intervals of time, T(R1), T(R4), T(R6)
> where loss is measured, and they look something like this:
> 
> time -> start         stop
> T(R1)   |-------------|
> T(R4)     |-------------|
> T(R6)        |-------------|
> 
> The IPPM Active metric of Loss would indicate that T(R1) is the
> measurement interval for describing the results, so it would be good to
> note this.
> 
> 
>           multipoint-to-multipoint
>               +------+                +------+
>           ---<>  R1  <>              <>  R6  <>---
>               +------+ \            / +------+
>                         \ +------+ /
>                          <>  R4  <>
>                           +------+ \
>               +------+              \ +------+
>           ---<>  R2  <>             <>  R7  <>---
>               +------+ \            / +------+
>                         \ +------+ /
>                          <>  R5  <>
>                         / +------+ \
>               +------+ /            \ +------+
>           ---<>  R3  <>              <>  R8  <>---
>               +------+                +------+
> 
> ...due to characteristics of the selected flows (where there may be time
> gaps between packets in a selected flow)?
>

---

From: Fioccola Giuseppe <[email-masked]>
Date: Tue, 12 Jun 2018 20:41:18 +0000

HI Al,
Thank you for sharing this.
I try to send the figure again (in any case it is like Figure 4 of RFC8321):

   ...BBBBBBBBB | AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA | BBBBBBBBB...

The idea is that, as you pointed out, the misalignment between the marking source routers gives an additional constraint and this value can be added to d (that already includes clock error and network delay).
All source nodes mark the traffic and, in general, the source measurement intervals can be of different lengths and with different offsets (as highlighted in both your figures) and this mismatch can be included into d.
However, the condition that must be satisfied to enable the method to function properly is that the available counting interval must be > 0, and that means: L - 2d > 0 for each measurement point on the multipoint path.
So, the mismatch between measurement intervals must satisfy this condition.

Of course, I will publish the new version before the IETF102 submission deadline :)

Giuseppe

-----Original Message-----
From: MORTON, ALFRED C (AL) [mailto:[email-masked]] 
Sent: martedì 12 giugno 2018 18:39
To: Fioccola Giuseppe <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]' <[email-masked]>; Tal Mizrahi ([email-masked]) <[email-masked]>
Subject: RE: New Version Notification for draft-fioccola-ippm-multipoint-alt-mark-03.txt

Hi Giuseppe,

I think a CR-removing application made a mess of your figure, below, despite our use of plain text.

I'll be better able to say what I think of your proposal for a new section after seeing all the info you kindly provided.  :-)

Al

> Subject: RE: New Version Notification for 
> draft-fioccola-ippm-multipoint- alt-mark-03.txt
> 
> Hi Al,
> This is a very good point and I think we need a dedicated Section (as 
> for
> RFC8321) to detail.
> As you have mentioned, RFC8321 explains this concept for 
> point-to-point flow in Section 3.2 "Timing Aspects", but the same 
> issue must be generalized for multipoint-to multipoint network.
> The total contribution of this mismatch between the marking source 
> routers gives an additional constraint and this value can be added to 
> d (that already includes clock error and network delay).
> However, in summary, the condition to be satisfied, for each 
> measurement point on the multipoint path, is that the available 
> counting interval must be > 0.
> Subject: RE: New Version Notification for 
> draft-fioccola-ippm-multipoint- alt-mark-03.txt
> 
> Hi Guiseppi,
> 
> I have read through much of your draft, and I have a question about 
> the measurement interval of the various multi* to multi* measurements.
> 
> measurement interval at R1 and R2 and R3 to some degree (but more 
> about this later).
> measurement interval for describing the results, so it would be good 
> to note this.
> 
> 
>           multipoint-to-multipoint
>               +------+                +------+
>           ---<>  R1  <>              <>  R6  <>---
>               +------+ \            / +------+
>                         \ +------+ /
>                          <>  R4  <>
>                           +------+ \
>               +------+              \ +------+
>           ---<>  R2  <>             <>  R7  <>---
>               +------+ \            / +------+
>                         \ +------+ /
>                          <>  R5  <>
>                         / +------+ \
>               +------+ /            \ +------+
>           ---<>  R3  <>              <>  R8  <>---
>               +------+                +------+
> 
> > [email-masked]' <[email-masked]>; 
> > Tal Mizrahi ([email-masked]) <[email-masked]>
> > Subject: [ippm] FW: New Version Notification for 
> > draft-fioccola-ippm- multipoint-alt-mark-03.txt
> >
> > Hi All,
> >
> > 3A__www.ietf.org_internet-2Ddrafts_draft-2Dfioccola-2Dippm-2Dmultipo
> > in
> > t-
> > o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=fiShY_CVpXGJ7HSXBG36auV
> > FJ UMZZ 
> > 3A__datatracker.ietf.org_doc_draft-2Dfioccola-2Dippm-2Dmultipoint-2D
> > al
> > t-
> > 2Dmark_&d=DwIGaQ&c=LFYZ-
> > o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=fiShY_CVpXGJ7HSXBG36auV
> > FJ UMZZ 
> > 3A__tools.ietf.org_html_draft-2Dfioccola-2Dippm-2Dmultipoint-2Dalt-2
> > Dm
> > ark-
> > 2D03&d=DwIGaQ&c=LFYZ-
> > o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=fiShY_CVpXGJ7HSXBG36auV
> > FJ UMZZ 
> > 3A__datatracker.ietf.org_doc_html_draft-2Dfioccola-2Dippm-2Dmultipoi
> > nt
> > -
> > o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=fiShY_CVpXGJ7HSXBG36auV
> > FJ UMZZ 
> > 3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dfioccola-2Dippm-2Dmultipoi
> > nt
> > -
> > o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=fiShY_CVpXGJ7HSXBG36auV
> > FJ UMZZ 
> > cortesemente pregati di darne immediata comunicazione al mittente e 
> > di provvedere alla sua distruzione, Grazie.
> >
> >
> >
> > this message and any attachments and advise the sender by return 
> > e-mail,
> Thanks.
> >
> >
> >
> > o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=fiShY_CVpXGJ7HSXBG36auV
> > FJ UMZZ