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

From: "Ackermann, Michael" <[email-masked]>
Date: Mon, 2 Dec 2019 00:00:11 +0000

Sorry for the delay in responding.  

This is very good, important work and will be more so as our networks grow increasing larger and more complex.    This is particularly true in the support of parallel paths and the documents overall attention to detail.  

As such,  I support  publication.  

Thanks

Mike 

-----Original Message-----
From: ippm <[email-masked]> On Behalf Of Brian Trammell (IETF)
Sent: Sunday, November 17, 2019 9:41 PM
To: IETF IPPM WG <[email-masked]>
Subject: [ippm] Working Group Last Call: draft-ietf-ippm-route-06

[External email]

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)
_______________________________________________
ippm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ippm

The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.

---

From: Joachim Fabini <[email-masked]>
Date: Mon, 2 Dec 2019 10:10:46 +0100

Delayed because of travel: yes, as co-author I believe that the document
is ready for publication (Ignacio's latest comments should be included).

regards
Joachim

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 2 Dec 2019 15:41:32 +0000 (UTC)

Brian & IPPM,
I believe the document is ready for publication.   It is detailed and thorough in defining metrics and terms for the changing nature of routing.
>From the point of view of enterprises, today what we have is is definitely not "your grandfather's route".   Servers may reside on WAN, cloud, hybrid-cloud, and so forth.   When we think of really using DNS-Service Discovery (potentially with IPv6 Anycast) for highly dynamic topology, then measurement and notation of the multiple paths for routing becomes critical.
I support this document.   I am especially pleased with the noting the reality of parallel and cloud subpaths.
 Parallel Paths:  Parallel paths are a reality of the Internet and a
      strength of advanced route assessment methods, so the metric must
      acknowledge this possibility.  Use of Equal Cost Multi-Path (ECMP)
      and Unequal Cost Multi-Path (UCMP) technologies are common sources
      of parallel subpaths.

   Cloud Subpath:  May contain hosts that do not decrement TTL or Hop
      Limit, but may have two or more exchange links connecting
      "discoverable" hosts or routers.  Parallel subpaths contained
      within clouds cannot be discovered.  The assessment methods only
      discover hosts or routers on the path that decrement TTL or Hop
      Count, or cooperate with interrogation protocols.  The presence of
      tunnels and nested tunnels further complicate assessment by hiding
      hops.

Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360 

    On Sunday, November 17, 2019, 06:41:03 PM PST, Brian Trammell (IETF) <[email-masked]> wrote:  
 
 Greetings, all,

Many thanks, cheers,

Brian (as co-chair)

---

From: Giuseppe Fioccola <[email-masked]>
Date: Wed, 4 Dec 2019 14:06:23 +0000

Dear All,
I went through the last version of the draft (including the last proposed changes by Jose' Ignacio) and I think it is ready for publication.
The route metric here described is an important complement for both active and passive measurements.

Best Regards,

Giuseppe

-----Original Message-----
From: ippm [mailto:[email-masked]] On Behalf Of J Ignacio Alvarez-Hamelin
Sent: Friday, November 22, 2019 2:09 PM
To: IETF IPPM WG <[email-masked]>
Subject: Re: [ippm] Working Group Last Call: draft-ietf-ippm-route-06

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,
>

---

From: Tommy Pauly <[email-masked]>
Date: Mon, 09 Dec 2019 12:04:17 -0800

Hello all,

Thanks for your reviews and feedback! This last call has now ended, and we will progress the document.

Based on the discussion on-list, we will expect an -07 revision before sending up to the IESG. Brian Trammell has graciously offered to shepherd the document.

Authors, please submit a revised version when ready.

Best,
Tommy

> On Nov 17, 2019, at 6:40 PM, Brian Trammell (IETF) <[email-masked]> wrote:
> 
> Greetings, all,
>