Subject: [ippm] Working Group Last Call: draft-ietf-ippm-route-06

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Mon, 18 Nov 2019 10:40:47 +0800

Greetings, all,

The IPPM working group intends to send draft-ietf-ippm-route-06 to the IESG for publication. This message begins a Working Group Last Call on to end on Monday 9 December 2019. Please send a message to [email-masked] stating whether you believe the document is ready for publication, and if not, please explain why not and/org provide comments to improve the document for publication.

Many thanks, cheers,

Brian (as co-chair)

---

From: J Ignacio Alvarez-Hamelin <[email-masked]>
Date: Fri, 22 Nov 2019 10:08:41 -0300

Dear all,

I support this draft as an author, and I think it is ready for publication. I only suggest some minor modifications on section 7 (the last paragraphs) to clarify the spirit of the text: 

Where it says :
==============8<----------------------
   Even though a particular hop may be understood as the amount of hops
   away from the source, a more detailed classification could be used.
   For example, a possible classification may be identify ICMP Time
   Exceeded packets coming from the same routers to those who have the
   same hop distance, IP address of the router which is replying and TTL
   or Hop Limit value of the received ICMP packet.

   Thus, the proposed methodology is based on this algorithm:

 ================================================================
  1  input:   W (window time of the measurement)
  2           i_t (time between two measurements)
  3           E (True: exhaustive, False: a single path)
  4           Dst (destination IP address)
  5  output:  Qs (quartiles for every hop and alt in the path(s) to Dst)
 ----------------------------------------------------------------
  6  T <? start_timer(W)
  7  while T is not finished do:
  8  |       start_timer(i_t)
  9  |       RTD(hop,alt) = advanced-traceroute(Dst,E)
 10  |       for each hop and alt in RTD do:
 11  |       |     Qs[Dst,hop,alt] <? ComputeQs(RTD(hop,alt))
 12  |       done
 13  |       wait until i_t timer is expired
 14  done
 15  return (Qs)
 ================================================================

==================>8--------

Should by replace by:
==================8<------- 

The identification of a specific Hop in traceroute is based on the IP origin address of the returned ICMP Time Exceeded packet, and on the distance identified by the value set in the TTL field inserted by traceroute. As this specific Hop can be reached by different paths, also the IP source and destination addresses of the traceroute packet need to be recorded. Finally, different return paths are distinguished by evaluating the ICMP Time Exceeded TTL (of the reply message): if this TTL is constant for different paths containing the same Hop, the return paths have the same distance. Moreover, this distance can be estimated considering that the TTL value is normally initialized with values 64, 128, or 255. The 5-tuple (origin IP, destination IP, reply IP, distance, response TTL) univocally identifies every measurement.

This algorithm below runs in the origin of the traceroute. It returns the Qs quartiles for every Hop and Alt (alternative paths because of balancing). The following parameters are used: W window time of the measurement, i_t time between two measurements, Dst destination IP address.

================================================================
 1  input:   W (window time of the measurement)
 2           i_t (time between two measurements)
 3           E (True: exhaustive, False: a single path)
 4           Dst (destination IP address)
 5  output:  Qs (quartiles for every Hop and Alt)
----------------------------------------------------------------
 6  T := start_timer(W)
 7  while T is not finished do:
 8  |       start_timer(i_t)
 9  |       RTD(Hop,Alt) = advanced-traceroute(Dst,E)
10  |       for each Hop and Alt in RTD do:
11  |       |     Qs[Dst,Hop,Alt] := ComputeQs(RTD(Hop,Alt))
12  |       done
13  |       wait until i_t timer is expired
14  done
15  return (Qs)
================================================================

During the time W, lines 6 and 7 assure that the measurement loop is made. Line 8 and 13 set a timer for each cycle of measurements. A cycle comprises the traceroutes packets, considering every possible Hop and the alternatives paths in the Alt variable (ensured in lines 9-12). Finally, lines 10 and 12 stores each measurement into the real-time quartiles computation.

==========>8-----

Best regards,

		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/
_______________________________________________________________

> On 17 Nov 2019, at 23:40, Brian Trammell (IETF) <[email-masked]> wrote:
> 
> Greetings, all,
> 
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm

---

From: <[email-masked]>
Date: Mon, 25 Nov 2019 09:01:42 +0000

Dear Ignacio,

As a co-author, I think the document is in good shap. I agree to the changes proposed by you and have no other comments. I think draft-ietf-ippm-route is ready for publication.

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: ippm <[email-masked]> Im Auftrag von J Ignacio Alvarez-Hamelin
Gesendet: Freitag, 22. November 2019 14:09
An: IETF IPPM WG <[email-masked]>
Betreff: Re: [ippm] Working Group Last Call: draft-ietf-ippm-route-06

Dear all,

Where it says :

Should by replace by:

==========>8-----

Best regards,

		Ignacio

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