Subject: [ippm] New draft on Advanced Route Metrics and Measurements

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 29 Jun 2017 01:10:05 +0000

IPPM,

Back at IETF-95 in Buenos Aires, the IPPM WG wanted to
see some "traceroute" support in the Registry,
but we didn't even have a metric to reference.
Many methods were available, producing differing results.
Now, with in-situ OAM, it's possible that there will 
be more advanced methods of measurement than ever before.
There are also some interesting RTD analysis 
possibilities which we describe. We've been working
on this draft in fits and starts since meeting in "BA".

We invite IPPM'ers to read our draft and share your 
reactions and comments here.

thanks and regards,
Ignacio, Joachim, and Al

-=-=-=-=-=-=-=-=-=-=-=-=-

A New Internet-Draft is available from the on-line Internet-Drafts directories.

     Title           : Advanced Unidirectional Route Assessment
     Authors         : José Ignacio Alvarez-Hamelin
                       Al Morton
                       Joachim Fabini
	Filename        : draft-amf-ippm-route-00.txt
	Pages           : 17
	Date            : 2017-06-28

Abstract:
   This memo introduces an advanced unidirectional route assessment
   metric and associated measurement methodology, based on the IP
   Performance Metrics (IPPM) Framework RFC 2330.  This memo updates RFC
   2330 in the areas of path-related terminology and path description,
   primarily to include the possibility of parallel subpaths.

https://tools.ietf.org/html/draft-amf-ippm-route-00

---

From: <[email-masked]>
Date: Thu, 29 Jun 2017 10:04:33 +0000

Hi Al,

I briefly read the draft. Reliably tracing one or more IP paths is a reasonable aim. Some comments:
- this is a standards track doc containing no requirement language.
- if this remains a standards track doc, the guidance on how to code packets must be well defined. 
   For the time being, a reader has an impression what to do, and an expert may indeed do so.
- the draft does not differentiate between equal paths along different routers and equal paths 
   between the same pair of routers (i.e. multiple parallel links). I think, the latter can't be detected. 
   This should be clarified.
- It is not clear how in-band-oam can be combined or used to complete the advanced route metrics. 
   Especially the multi-domain and single-domain measurement should be decoupled more 
   clearly.
- If the authors think that the guidance "change several fields to keep the checksum of different 
   packets identical" doesn't require any security discussion, the authors should say so in the 
   security section.

Regards,

Ruediger

-----Ursprüngliche Nachricht-----
Von: ippm [mailto:[email-masked]] Im Auftrag von MORTON, ALFRED C (AL)
Gesendet: Donnerstag, 29. Juni 2017 03:10
An: [email-masked]
Cc: [email-masked]
Betreff: [ippm] New draft on Advanced Route Metrics and Measurements

IPPM,

Back at IETF-95 in Buenos Aires, the IPPM WG wanted to see some "traceroute" support in the Registry, but we didn't even have a metric to reference.
Many methods were available, producing differing results.
Now, with in-situ OAM, it's possible that there will be more advanced methods of measurement than ever before.
There are also some interesting RTD analysis possibilities which we describe. We've been working on this draft in fits and starts since meeting in "BA".

We invite IPPM'ers to read our draft and share your reactions and comments here.

thanks and regards,
Ignacio, Joachim, and Al

Abstract:

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

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 29 Jun 2017 16:23:35 +0000

Hi Rüdiger,

Thanks for sharing your comments on the ippm-list.
Ignacio, Joachim and I appreciate your timely
and helpful review! You've started the To Do list
for the next rev.

please see more replies below,
Al

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, June 29, 2017 6:05 AM
> To: MORTON, ALFRED C (AL)
> Cc: [email-masked]; [email-masked]
> Subject: AW: New draft on Advanced Route Metrics and Measurements
> 
> Hi Al,
> 
[ACM] 
Yes. We have only taken the step to define new parameters, metrics, methods,
and analysis as *concepts* so far, without requirements language.
If folks agree that the descriptions are clear enough to proceed,
we'll adopt the RFC 2119 terms and move toward tighter specifications.

>    This should be clarified.
[ACM] 
The concept of a *discoverable* host is at the root of your comment.
We haven't provided a formal definition for this term yet and
it needs some further discussion, but it will probably include the 
relevant requirements for hosts and routers (RFC 1122),
and some additional requirements that apply for hybrid methods, 
at least.

Specific to your question:
If a pair of discovered hosts identify two different IP addresses,
then they will appear to be different hosts.

If a pair of discovered hosts identify two different IP addresses,
and the IP addresses resolve to the same host name (in the DNS),
then they will appear to be the same hosts.

If a discovered host always replies using the same IP address,
regardless of the interface a packet arrives on,
then multiple parallel links cannot be detected at the IP layer.

If parallel links between routers are aggregated below the IP layer,
IOW, all links share the same pair of IP addresses,
then the existence of these parallel links can't be detected at IP
layer.

>    Especially the multi-domain and single-domain measurement should be
[ACM] 
Thanks, I think we all need to better understand what we'll be able to
do with the new hybrid methods  (we are calling both the "new-ish" 
active methods we describe, and new hybrid methods, "advanced" methods).
It seems likely that combinations of route information derived
from active and hybrid methods will provide additional information.
This is particularly true if hosts inside an in-situ domain are 
"not discoverable" except when using Hybrid Type I methods.

> - If the authors think that the guidance 
> "change several fields to keep the checksum of different
[ACM] 
Thanks for that.  We only have the most basic security considerations
right now, which only address active and passive methods. 
There will be *new* security considerations for Hybrid Type I 
methods, and we certainly will reference them when available
or add them in the text.

We may also need to explain that the process you quoted above
is only part of the active methods, and it is executed at the Source
host before sending a packet.  Perhaps that is sufficient
explanation, unless I'm overlooking something?

> Back at IETF-95 in Buenos Aires, the IPPM WG wanted to see some
> "traceroute" support in the Registry, but we didn't even have a metric
> to reference.
> There are also some interesting RTD analysis possibilities which we
> describe. We've been working on this draft in fits and starts since
> meeting in "BA".
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_draft-2Damf-2Dippm-2Droute-2D00&d=DwIFAw&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=V2yRRSNIWQVXxuQy-
> ZLI3oPhDjf_iSxw69Z_OiUManw&s=N99w_k6mo_iuyB-
> u3Jpp3jdMihOJNyOzJnfNzbhGQzQ&e=
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ippm&d=DwIFAw&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=V2yRRSNIWQVXxuQy-
> ZLI3oPhDjf_iSxw69Z_OiUManw&s=LIgwFuKTWJdv9lbvno2SxHkMfMvFpFYRd5P9AQsXYOs
> &e=

---

From: <[email-masked]>
Date: Fri, 30 Jun 2017 06:56:11 +0000

Hi Al,

thanks for your fast response. One more point while I'm reading. I'm not an in-situ OAM expert, but as you add information to a packet, this should impact the checksum of that packet too. If this is true for in-situ-oam mechanisms (I don't know), and an identical end-to-end checksum field is part of the Advanced Route Metrics functionality, the latter draft needs to discuss application and limits of which method when.

Your replies line out well what should be added (if the work is picked up by IPPM).

Regards,

Rüdiger

-----Ursprüngliche Nachricht-----
Von: MORTON, ALFRED C (AL) [mailto:[email-masked]] 
Gesendet: Donnerstag, 29. Juni 2017 18:24
An: Geib, Rüdiger <[email-masked]>
Cc: [email-masked]; [email-masked]
Betreff: RE: New draft on Advanced Route Metrics and Measurements

Hi Rüdiger,

Thanks for sharing your comments on the ippm-list.
Ignacio, Joachim and I appreciate your timely and helpful review! You've started the To Do list for the next rev.

>    For the time being, a reader has an impression what to do, and an 
[ACM]
Yes. We have only taken the step to define new parameters, metrics, methods, and analysis as *concepts* so far, without requirements language.
If folks agree that the descriptions are clear enough to proceed, we'll adopt the RFC 2119 terms and move toward tighter specifications.

[ACM]
The concept of a *discoverable* host is at the root of your comment.
We haven't provided a formal definition for this term yet and it needs some further discussion, but it will probably include the relevant requirements for hosts and routers (RFC 1122), and some additional requirements that apply for hybrid methods, at least.

Specific to your question:
If a pair of discovered hosts identify two different IP addresses, then they will appear to be different hosts.

If a pair of discovered hosts identify two different IP addresses, and the IP addresses resolve to the same host name (in the DNS), then they will appear to be the same hosts.

If a discovered host always replies using the same IP address, regardless of the interface a packet arrives on, then multiple parallel links cannot be detected at the IP layer.

If parallel links between routers are aggregated below the IP layer, IOW, all links share the same pair of IP addresses, then the existence of these parallel links can't be detected at IP layer.

>    Especially the multi-domain and single-domain measurement should be 
[ACM]
Thanks, I think we all need to better understand what we'll be able to do with the new hybrid methods  (we are calling both the "new-ish" 
active methods we describe, and new hybrid methods, "advanced" methods).
It seems likely that combinations of route information derived from active and hybrid methods will provide additional information.
This is particularly true if hosts inside an in-situ domain are "not discoverable" except when using Hybrid Type I methods.

> authors should say so in the
[ACM]
Thanks for that.  We only have the most basic security considerations right now, which only address active and passive methods. 
There will be *new* security considerations for Hybrid Type I methods, and we certainly will reference them when available or add them in the text.

We may also need to explain that the process you quoted above is only part of the active methods, and it is executed at the Source host before sending a packet.  Perhaps that is sufficient explanation, unless I'm overlooking something?

> Von: ippm [mailto:[email-masked]] Im Auftrag von MORTON, ALFRED 
> C
> (AL)

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Fri, 30 Jun 2017 13:03:47 +0000

Hi Rüdiger, 

> Sent: Friday, June 30, 2017 2:56 AM
> thanks for your fast response. One more point while I'm reading. I'm not
> an in-situ OAM expert, but as you add information to a packet, this
> should impact the checksum of that packet too. 
[ACM] 
Fortunately, the in-situ data fields are removed at the 
domain boundary, so the remainder of the Internet path
should see a single flow again (needs checking though).

> If this is true for in-
> situ-oam mechanisms (I don't know), and an identical end-to-end checksum
> field is part of the Advanced Route Metrics functionality, the latter
> draft needs to discuss application and limits of which method when.
[ACM] 
You've identified another important area for interaction
among the "route" and "in-situ" author teams, and the WG.

> Your replies line out well what should be added (if the work is picked
[ACM] 
Thanks again for your supportive comments,
Al
(for the co-authors)

> Yes. We have only taken the step to define new parameters, metrics,
> methods, and analysis as *concepts* so far, without requirements
> language.
> If folks agree that the descriptions are clear enough to proceed, we'll
> adopt the RFC 2119 terms and move toward tighter specifications.
> 
> We haven't provided a formal definition for this term yet and it needs
> some further discussion, but it will probably include the relevant
> requirements for hosts and routers (RFC 1122), and some additional
> requirements that apply for hybrid methods, at least.
> 
> If a pair of discovered hosts identify two different IP addresses, and
> the IP addresses resolve to the same host name (in the DNS), then they
> will appear to be the same hosts.
> 
> regardless of the interface a packet arrives on, then multiple parallel
> links cannot be detected at the IP layer.
> 
> IOW, all links share the same pair of IP addresses, then the existence
> of these parallel links can't be detected at IP layer.
> 
> 
> It seems likely that combinations of route information derived from
> active and hybrid methods will provide additional information.
> This is particularly true if hosts inside an in-situ domain are "not
> discoverable" except when using Hybrid Type I methods.
> 
> There will be *new* security considerations for Hybrid Type I methods,
> and we certainly will reference them when available or add them in the
> text.
> 
> We may also need to explain that the process you quoted above is only
> part of the active methods, and it is executed at the Source host before
> sending a packet.  Perhaps that is sufficient explanation, unless I'm
> overlooking something?
> 
> >
> > Regards,
> >
> > Ruediger
> >
> >