Isn’t In-Band OAM supposed to expose the actual Path Information? More and more services need to know network delay & path information. That is why there are so many network monitoring companies popping up in offering delay and other characteristics of network to end points.
However, it has been difficult for network operators to expose its exact paths due to the confidentiality of its network topology. It makes more sense for end points to inquire pseudo path information instead of real path information, and more realistic from networks’ controller or management system. My two cents Linda Dunbar From: tsv-area [mailto:tsv-area-boun...@ietf.org] On Behalf Of Spencer Dawkins at IETF Sent: Wednesday, July 12, 2017 10:30 AM To: Bob Briscoe <i...@bobbriscoe.net> Cc: tsv-area@ietf.org >> tsv-area@ietf.org <tsv-area@ietf.org>; pa...@irtf.org Subject: Re: [Panrg] Proposed Path Aware Networking RG Brian, Bob, and Lars, On Wed, Jul 12, 2017 at 7:52 AM, Bob Briscoe <i...@bobbriscoe.net<mailto:i...@bobbriscoe.net>> wrote: Brian, 1/ The IRTF sounds like a good landing point for all the previous attempts to get the IETF to add path-awareness protocols. BTW, this goes back a lot further than SPUD. A good summary of pre-2007 efforts in this space is in a section of Pasi's draft on this from 2007: https://tools.ietf.org/html/draft-sarolahti-tsvwg-crosslayer-01#section-6 , which reminds us of TRIGTRAN (2002), INTERSEC (2003), ALIAS (2003) and TERNLI (2006). [I wrote this before seeing Lars's email pointing to TERNLI] 2/ The advantages of opacity (invisibility) of path characteristics should also be in scope. In general the tone of the text seems to be "awareness = good; unawareness = bad". If I have detected this tone correctly, it would represent an implicit value judgement; which would not be a good starting point for research. * You've alluded to potential security advantages in the phrase "exploration of trust and risk models". * There are also evolvability advantages. I recall David Clark (I think) saying that the rudimentary interface between transport and network was a feature not a bug. Admittedly it's a pain for the transport to have to discover available path capacity, path delay, etc. However, the alternative would have been to require all L2 technologies to be able to give information that would require them to make assumptions about the transport. That in turn would ossify transports and L2 technologies. We might be saying that the Internet is moving into a new phase where performance is now more important than evolvability. That's a point to debate, but I know you, at least, still believe that stack evolution will remain important. Bob On 12/07/17 07:21, Brian Trammell (IETF) wrote: Greetings, all, We'll be having a first meeting of the proposed Path Aware Networking (PAN) RG at IETF 99 in Prague next week, 13:30 Wednesday in Congress Hall 3. Since bringing path awareness to the endpoint has been the focus, at least in part, of a couple of running TSV working groups (MPTCP, TAPS), this RG seems to be of general interest to the transport area. Olivier Bonaventure will give a review and overview of research to date in this space, and Adrian Perrig will present a fully path-aware Internet architecture, as an illustration of what is possible when path-awareness is promoted to a first-order goal. From our proposed charter (https://datatracker.ietf.org/group/panrg/about): The Internet architecture assumes a division between the end-to-end functionality of the transport layer and the properties of the path between the endpoints. The path is assumed to be invisible, homogeneous, singular, with dynamics solely determined by the connectivity of the endpoints and the Internet control plane. Endpoints have very little information about the paths over which their traffic is carried, and no control at all beyond the destination address. Increased diversity in access networks, and ubiquitous mobile connectivity, have made this architecture's assumptions about paths less tenable. Multipath protocols taking advantage of this mobile connectivity begin to show us a way forward, though: if endpoints cannot control the path, at least they can determine the properties of the path by choosing among paths available to them. This research group aims to support research in bringing path awareness to transport and application layer protocols, and to bring research in this space to the attention of the Internet engineering and protocol design community. The scope of work within the RG includes, but is not strictly limited to: - communication and discovery of information about the properties of a path on local networks and in internetworks, exploration of trust and risk models associated with this information, and algorithms for path selection at endpoints based on this information. - algorithms for making transport-layer scheduling decisions based on information about path properties. - algorithms for reconciling path selection at endpoints with widely deployed routing protocols and network operations best practices. The research group's scope overlaps with existing IETF and IRTF efforts, and will collaborate with groups chartered to work on multipath transport protocols (MPTCP, QUIC, TSVWG), congestion control in multiply-connected environments (ICCRG), and alternate routing architectures (e.g. LISP), and is related to the questions raised in the multiple recent BoF sessions that have addressed path awareness and multiply-connected networks (e.g. SPUD, PLUS, BANANA). he PAN(P)RG intends to meet at each IETF meeting until a determination is made whether or not to charter it. Afterward, the RG intends to meet at 1-3 IETF meetings per year, and hold one workshop per year, colocated with a related academic conference. Brian, thank you for taking this on, in the first place. We've been dancing around the topic in the IETF for a while, and if I've learned anything from attending that dance, this isn't engineering (yet) and isn't IETF timescale (yet). So, the IRTF seems appropriate. Lars and Bob, thank you for the pointers to prior art. I was aware of some of that (for better or worse, I co-chaired the TRIGTRAN BoF, but co-chairing PILC might have made up for some of that), but certainly not all of it, and much of what you two named happened while I was off doing RAI stuff after PILC concluded. I look forward to the first PANRG session in Prague, and I'll encourage TSV area chairs to consider whether PANRG should be on their conflict lists for future IETF meetings. Travel safely, and I'll see many of you next week. Spencer, as TSV AD and at-large IRSG member
