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

["MORTON, ALFRED C (AL)" <[e-mail]>]

Hi Rüdiger,

Now addressing one of your previous comments:
> > - 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.
> >  

I think the methods of measurement have several parallel aspects:
  Active    Multi-domain
  Hybrid    Single domain  with  Interrogation Protocol (in-situ OAM)

Additionally, there can be active or hybrid tracing for 
network technologies that are inherently single domain, 
but the WG needs to discuss how far we expand the scope of work 
for this memo. 

OTOH, I've given some thought to combinations of 
Active and Hybrid Methods, and there will be a 
new section to set requirements that will simplify
the combination process. Some rules (with standards-track
terminology, as you suggested) will help.

regards,
Al


> -----Original Message-----
> From: MORTON, ALFRED C (AL)
> Sent: Friday, June 30, 2017 9:04 AM
> To: '[e-mail]'
> Cc: [e-mail]; [e-mail]
> Subject: RE: New draft on Advanced Route Metrics and Measurements
> 
> Hi Rüdiger,
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: Friday, June 30, 2017 2:56 AM
> > To: MORTON, ALFRED C (AL)
> > Cc: [e-mail]; [e-mail]
> > Subject: AW: New draft on Advanced Route Metrics and Measurements
> >
> > 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.
> [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
> > up by IPPM).
> [ACM]
> Thanks again for your supportive comments,
> Al
> (for the co-authors)
> 
> >
> > Regards,
> >
> > Rüdiger
> >
> > -----Ursprüngliche Nachricht-----
> > Von: MORTON, ALFRED C (AL) [mailto:[e-mail]]
> > Gesendet: Donnerstag, 29. Juni 2017 18:24
> > An: Geib, Rüdiger <[e-mail]>
> > Cc: [e-mail]; [e-mail]
> > 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.
> >
> > please see more replies below,
> > Al
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]]
> > > Sent: Thursday, June 29, 2017 6:05 AM
> > > To: MORTON, ALFRED C (AL)
> > > Cc: [e-mail]; [e-mail]
> > > Subject: AW: New draft on Advanced Route Metrics and Measurements
> > >
> > > 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.
> > [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.
> >
> > > - 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.
> > [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.
> >
> >
> > > - 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.
> > [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
> > >    packets identical" doesn't require any security discussion, the
> > > authors should say so in the
> > >    security section.
> > [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?
> >
> > >
> > > Regards,
> > >
> > > Ruediger
> > >
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: ippm [mailto:[e-mail]] Im Auftrag von MORTON,
> ALFRED
> > > C
> > > (AL)
> > > Gesendet: Donnerstag, 29. Juni 2017 03:10
> > > An: [e-mail]
> > > Cc: [e-mail]
> > > 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
> > >
> > > -=-=-=-=-=-=-=-=-=-=-=-=-
> > >
> > > 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://urldefense.proofpoint.com/v2/url?u=https-
> > > 3A__tools.ietf.org_html_draft-2Damf-2Dippm-2Droute-
> 2D00&d=DwIFAw&c=LFY
> > > Z-
> > > o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=V2yRRSNIWQVXxuQy-
> > > ZLI3oPhDjf_iSxw69Z_OiUManw&s=N99w_k6mo_iuyB-
> > > u3Jpp3jdMihOJNyOzJnfNzbhGQzQ&e=
> > >
> > > _______________________________________________
> > > ippm mailing list
> > > [e-mail]
> > > 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=LIgwFuKTWJdv9lbvno2SxHkMfMvFpFYRd5P9AQsXY
> > > Os
> > > &e=