Re: [Tvr] First draft of problem statement

[Joel Halpern <[e-mail]>]

Generally working groups do better with narrow focus.

Having said that, my concern was combining the problem of routing 
adapting to planned changes with the problem of turning routing into a 
store and forward network (DTN does an interesting job there.)

Yours,

Joel

On 10/31/2022 4:28 AM, Dirk Trossen wrote:
>
> Dear all,
>
> Addressing by anything but an IP address does not need to lead to ICN 
> like ephemeral storage architectures, though. Having the capability to 
> deal with time-variant routing decision would greatly support ideas 
> like ‘routing on service addresses’ (ROSA) 
> (https://www.ietf.org/id/draft-trossen-rtgwg-rosa-00.html), which has 
> been submitted to the RTG WG as discussion in the next IETF (scheduled 
> now for the Thursday slot of the RTG WG).
>
> Here, ROSA carries service information in IPv6 EHs for a shim overlay 
> to make routing and forwarding decisions on that information. The 
> selection of the appropriate IPv6 destination (called a service 
> instance in ROSA) may be based on dynamic, down to request-level, 
> decisions (we developed a simple round robin that can operate linked 
> to computing information, as an example), but a time-variant decision 
> may equally be useful.
>
> The statement that “/The larger value of TVR (IMO) is that a planned 
> loss (or gain) of an adjacency can avoid tripping into recovery or 
> rediscovery mechanisms/.” is crucial and captures my understanding of 
> TVR very well. But when thinking of routing on service addresses as an 
> approach, the recovery/rediscovery mechanism may well look quite 
> different when, well, routing on service addresses but network locators.
>
> Best,
>
> Dirk
>
> *From:*Tvr <[e-mail]> *On Behalf Of *Joel Halpern
> *Sent:* 28 October 2022 20:06
> *To:* Beck, Micah <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [Tvr] First draft of problem statement
>
> If the network holds packets for any significant length of time, this 
> produces results which affect and disrupt the application behavior.  
> if you want a long term store network, look at the DTN work.  The 
> applications themselves behave differently because they know that the 
> network has different properties.  (One could even argue that the 
> bufferbloat work shows that even the delays we have currently in the 
> routing / forwarding network when we buffer for congestion cause 
> application difficulties.)
>
> This work is being considered in the context of IP routing. And IP 
> Forwarding.  The packets are addressed by IP.  The DNS or other 
> resolution behaviors are driven by the applications at the end systems.
>
> My understanding is that the goal of this work is to allow the routing 
> and forwarding system to be aware of expected changes in the 
> topology.  Changing the forwrading paradigm would be a different task.
>
> Yours,
>
> Joel
>
> On 10/28/2022 2:00 PM, Beck, Micah wrote:
>
>         As I see it, the basis for route computation in DTN and IP is
>         the known source and destination of the data, while the basis
>         for route computation in ICN is the nature of the data.
>
>     Today, it is unusual for an Internet service request to be
>     addressed directly by IP address - we use domain names (e.g. in
>     URLs). A domain may indeed correspond to an IP address that names
>     a unique network interface. However it is common for a domain to
>     resolve to a set of IP addresses or perhaps to a single IP address
>     that is routed to one of a set of network interfaces via BGP
>     anycast. In either case, the network interface that is the target
>     of the request is determined with reference to the network
>     topology. If the topology changes, the target may become
>     inaccessible or it may no longer be an appropriate one or the best
>     choice.
>
>     As you point out, ICN copes with this kind of situation through
>     content-based addressing. In contrast, requests that are resolved
>     to an IP address can either be rerouted or they can fail. In the
>     current environment, the resolution of a domain to an IP address
>     is generally performed immediately before making a service
>     request, so there is a limited window for serious changes to
>     topology. If the target becomes unavailable, the request fails and
>     domain resolution may be repeated before retrying.
>
>     However in the case of TVR, if data were to be held for a longer
>     period at any point after domain resolution occurred, the topology
>     could change quite dramatically. In this case it may be preferable
>     for the service request to fail then to continue to try and reach
>     the IP address originally targeted. It depends on many factors
>     that may be difficult or impossible for the Network layer to take
>     account of,
>
>         “/The larger value of TVR (IMO) is that a planned loss (or
>         gain) of an adjacency can avoid tripping into recovery or
>         rediscovery mechanisms/.“  I think this is an especially
>         eloquent expression of what we are after.
>
>     Please forgive my ignorance on this topic, but how significant a
>     cost is "/tripping into recovery or rediscovery mechanisms”//?
>     /Especially given the above analysis that such mechanisms are in
>     some common and important cases used as an alternative to
>     content-based routing as a way to find a target that is
>     topologically well matched to a particular request.
>
>     There is an argument that use of topologically-informed domain
>     resolution is now a means of service request routing. This has
>     moved responding to major changes in topology out of the domain
>     that the IP-address Network layer can deal with “completely and
>     correctly”. That would mean it should be left to a higher layer.
>     At least according to this argument.
>
>     /micah
>
>
>
>         On Oct 28, 2022, at 10:38 AM, [e-mail] wrote:
>
>         One direction I would like to try to steer us away from is
>         conflating TVR with ICN.  As I see it, the basis for route
>         computation in DTN and IP is the known source and destination
>         of the data, while the basis for route computation in ICN is
>         the nature of the data.  What I think distinguishes TVR (and
>         DTN) from more familiar IP is (a) the way in which the route
>         is computed, given the source and destination, in light of
>         known future variations in adjacency and (b) how to enable the
>         transmitted data to survive those changes in adjacency as it
>         makes its way through the network.  The latter involves
>         storage, as does ICN, but the operational context of the
>         storage is different.
>
>         Scott Burleigh
>
>         *From:*Joel Halpern <[e-mail]>
>         *Sent:*Thursday, October 27, 2022 9:40 PM
>         *To:*[e-mail]
>         *Cc:*[e-mail]
>         *Subject:*Re: [Tvr] First draft of problem statement
>
>         I would suggest being very careful about the path described
>         below.  Not because it is wrong.  But because it seems to be a
>         different problem.  The DTN and ICN work deals with networks
>         of devices which store things for later transmission.  To the
>         degree that we are describing an IP Routing problem of
>         reacting to changes in topology, that is not a storage and
>         later transmission problem.  If we mix the two, I for one will
>         find it quite confusing.
>
>         Yours,
>
>         Joel
>
>         On 10/27/2022 11:35 PM,[e-mail]:
>
>             Hi, Micah.  As you’ve reminded me (off-list
>             communication), we have been talking about this sort of
>             thing for many years.  One way of looking at it is to say
>             that there is actually a fine line between “communication”
>             and “storage”.  Communication, in essence, is the copying
>             – to some location – of data currently stored at a
>             different location; in order to do this we usually first
>             copy it to some other (notional) location, which we term a
>             communication “medium”.  Interplanetary networking is a
>             good example: the length of time the data resides in the
>             medium (which we no longer call “the ether”) is the
>             communication latency.  More prosaically, if I want to
>             store a locker combination very securely for two or three
>             days then maybe I write it on a piece of paper and mail it
>             to myself.
>
>             From this perspective, we might look at TVR as more
>             explicitly the selection of a sequence of locations to
>             which we want data to be copied; that sequence is a
>             “route” and by acknowledging the storage nature of the
>             operation we tolerate variance in the timeline of the copy
>             operations.
>
>             Scott
>
>             *From:*Tvr<[e-mail]>
>             <mailto:[e-mail]>*On Behalf Of*Beck, Micah
>             *Sent:*Thursday, October 27, 2022 2:19 PM
>             *To:*vinton cerf<[e-mail]> <mailto:[e-mail]>
>             *Cc:*Beck, Micah<mbeck=[e-mail]>
>             <mailto:mbeck=[e-mail]>;[e-mail]; Tony
>             Li<[e-mail]> <mailto:[e-mail]>; Rick
>             Taylor<[e-mail]>
>             <mailto:[e-mail]>; Jorge
>             Amodio<[e-mail]> <mailto:[e-mail]>
>             *Subject:*Re: [Tvr] First draft of problem statement
>
>             Here are some thoughts about how the Transport and
>             Application layers might work in a TVR-based network
>             environment.
>
>             While some applications can work with the weak guarantees
>             of a best-effort network, providing a more robust model
>             seems to be key to adoption and growth. For this reason
>             TCP does its best to ensure data integrity, in-order
>             delivery and to maintain connection state and continuity
>             in the face of interruption. TCP trades off these
>             desirable characteristics for increased latency.
>
>             In the case of TVR, service interruptions may be more
>             severe than are widely acceptable to applications that use
>             TCP. A TCP connection may time out, or an application may
>             simply fail to function adequately in the face of a long
>             enough pause in data transfer. For some applications it is
>             better to make weaker assumptions about network
>             availability than to make strong assumptions which are not
>             satisfied (resulting in error conditions).
>
>             Is it possible for a Transport layer service to help
>             overcome long pauses in data transfer? The answer is yes,
>             if that Transport layer is willing to manage enough
>             transfer state to enable some applications to continue
>             functioning during such pauses.
>
>             A minimal example of an application that is “always
>             available during disconnection” is text messaging. Because
>             the application buffers messages until they can be sent,
>             the end user experience is not changed by a lack of
>             connectivity. Interactive conversations experience delays,
>             but depending on end user expectation that may be acceptable.
>
>             The amount of state that would have to be managed depends
>             on the application. An audio streaming service might want
>             the end system to store enough music to get through a
>             pause uninterrupted. A map application might want it to
>             store enough maps and instructions to get to a
>             destination. Applications that use larger data types
>             (videos, satellite imagery, executable images) might
>             require substantially more storage to enable continued
>             operation during pauses in connectivity.
>
>             All Internet Transport layers other than UDP manage state.
>             TCP manages send and receive queues. SCTP manages multiple
>             queues. What I am suggesting is more extreme, but enabling
>             applications to work well in an environment that does not
>             provide continuous connectivity is a major challenge.
>
>             If it sounds like I am suggesting that some applications
>             might require multiple gigabytes of storage to enable
>             continuous operations, that is correct. However it is not
>             necessary that the burden be located entirely at a single
>             end node. A large connection state could be directed to a
>             specialized storage appliance in the LAN.
>
>             The intention of this proposal is not simply to enable
>             asynchronous data transfer in a sometimes disconnected
>             environment, but to enable as rich an interaction as
>             possible using the Transport layer as a stateful surrogate
>             for a remote node. This might include enabling some
>             behaviors specified by the remote node. These would have
>             to be limited in scope for reasons of security and
>             stability (not wanting to recreate Java applets!)
>
>             It is worth noting that the strategy of using edge storage
>             and processing to overcome connectivity issues is
>             currently being pursued by industry players, including
>             Apple, Google and Amazon. However in those cases the edge
>             devices are closed and the resources are usable only
>             within the ecosystems of each company.
>
>             The management of transfer state is part of the network
>             stack. Generalizing the Network layer without considering
>             how this increases the burden of responsibility on the
>             Transport layer is leaving part of the problem out of the
>             picture.
>
>             Best regards,
>
>             /micah
>
>
>
>
>
>                 On Oct 26, 2022, at 10:02 PM, vinton cerf
>                 <[e-mail]> wrote:
>
>
>                 	
>
>                 You don't often get email [e-mail]
>                 why this is important
>                 <https://aka.ms/LearnAboutSenderIdentification>
>
>                 	
>
>                 see delay and disruption tolerant networks (DTN)
>
>                 v
>
>                 On Tue, Oct 25, 2022 at 12:28 PM Beck, Micah
>                 <mbeck=[e-mail]> wrote:
>
>                     Hi all TVRers!
>
>                     I am interested in using IP without latency bounds
>                     or minimum connectivity requirements to provide
>                     digital connnectivity to locations where broadband
>                     as currently defined by the telecommunications
>                     industry will not reach soon, or perhaps ever. I
>                     am seeking feedback on whether this category of
>                     use cases fits in with the intended scope of the
>                     TVR working group.
>
>                     In such cases, applications may use edge storage
>                     and processing resources to hide or overcome high
>                     latency and disconnection. An edge resource may
>                     have several possible “last mile” links, and their
>                     endpoints may be predictable, but the timing and
>                     availability may vary greatly even if there is a
>                     nominal schedule. Thus, the topology is not as
>                     unpredictable as MANET, but it has a great need
>                     for fault tolerance through the use of multiple
>                     alternative last-mile links. It is similar in some
>                     ways to cases handled by DTN, but I believe the
>                     timing predictability assumptions are weaker.
>
>                     Some examples include:
>
>                     1. Connection through an aerial vehicle such as a
>                     blimp or LEO satellite.
>
>                     2. Storage carried on a ground or aerial vehicle
>                     that is used as data transfer by moving it between
>                     a wired or wireless point of connectivity to the
>                     backbone and the edge network. Amazon’s
>                     Snow{Flake,Ball,Mobile} line of products are
>                     proprietary Cloud versions of this “data ferrying”
>                     approach. It has also been used in many
>                     specialized scenarios including Wildfire
>                     Management scenarios and for email connectivity to
>                     remote villages in India. Other examples that
>                     might take advantage of scheduled ground vehicles
>                     include disaster response (where National Guard
>                     vehicles could be organized to move data in a
>                     predictable manner while also moving physical good
>                     or people) or remote education (where school buses
>                     run on predictable schedules reaching remote rural
>                     homes).
>
>                     3. Use of links that are highly intermittent,
>                     noisy or have highly variable transmission
>                     characteristics (e.g. error rate).  Various forms
>                     of underinvested community networking may fall
>                     into this category.
>
>                     In terms of how these cases may differ from what
>                     has been considered in scope for TVR up to this point:
>
>                     A. It may be necessary to utilize periods of
>                     connectivity of very short duration, or which have
>                     characteristics that are weaker than is generally
>                     assumed (high error rate for example). This may
>                     require different transport or application layer
>                     algorithms in order to take advantage of bandwidth
>                     which is available (and which might be quite high
>                     in some cases). This is not just a
>                     scheduling/routing problem but a latency-tolerance
>                     issue.
>
>                     B. If edge devices utilize a form of content-based
>                     or CDN-like subscription to determine which data
>                     to transfer across the last mile, then a routing
>                     scheme that is not based solely on destination
>                     address may be necessary. A specific content- or
>                     policy-based data movement policy might be
>                     implemented in overlay, but it would still require
>                     access to low layer topological and temporal
>                     information which may be held in routing tables in
>                     order to make informed choices.
>
>                     An example of case B arises when a large storage
>                     resource (e.g, a ground vehicle carrying storage
>                     laden with deliverable content) becomes
>                     temporarily available to an edge device (e.g.
>                     parked within connectivity reach of a WLAN) but it
>                     is not practical or desired to move the entire
>                     contents of the storage resource to the edge
>                     device. We would like the movement of data to be
>                     mediated by policy (which is not part of the TVR
>                     mechanism) but informed by topological knowledge
>                     that is available to the TVR routing algorithm.
>
>                     Without case B, the hard-to-connect edge network
>                     must rely on the same repeated unicast solution
>                     that is used in overprovisioned networks.
>
>                     My question: is this in scope for TVR, does it fit
>                     into another existing framework or working group,
>                     or is it a different category that would have to
>                     be considered separately from the current taxonomy
>                     of stable, predictable or highly dynanmic?
>
>                     Thanks for your attention,
>
>                     /micah
>
>                     Micah Beck
>
>                     Associate Professor, EECS
>
>                     University of Tennessee, Knoxville
>
>
>
>
>
>                         On Oct 25, 2022, at 9:45 AM, Jorge Amodio
>                         <[e-mail]> wrote:
>
>
>                         	
>
>                         You don't often get email
>                         [e-mail] why this is
>                         important
>                         <https://aka.ms/LearnAboutSenderIdentification>
>
>                         	
>
>                         I believe we are going to have stable,
>                         predictable/planned dynamic, and random dynamic.
>
>                         Jorge
>
>                         On Tue, Oct 25, 2022 at 8:24 AM Tony Li
>                         <[e-mail]> wrote:
>
>                             Rick,
>
>                             If you consider the cases of vehicle
>                             networks and satellites, both are highly
>                             dynamic topologies. See the use cases
>                             document.
>
>                             Tony
>
>
>
>
>
>                                 On Oct 24, 2022, at 11:20 PM, Rick
>                                 Taylor
>                                 <[e-mail]> wrote:
>
>                                 Hi Tony
>
>                                 I think dynamic topologies are for
>                                 Manet to fix.  Here I think we are
>                                 discussing stable topologies but with
>                                 an extra time dimension.
>
>                                 Does that make any sense?
>
>                                 Rick
>
>                                 Sent from my phone.
>
>                                 On 24 Oct 2022 21:46, Tony Li
>                                 <[e-mail]> wrote:
>
>
>                                 Rick,
>
>                                 One more thought:
>
>                                 Our conventional mechanisms for
>                                 protocol scaling have always been to
>                                 create hierarchy based on a static
>                                 topology.  A dynamic topology throws
>                                 that out the window.  How do we
>                                 achieve scalabity?
>
>                                 Tony
>
>                                 > On Oct 24, 2022, at 1:31 PM, Rick
>                                 Taylor
>                                 <[e-mail]> wrote:
>                                 >
>                                 > Hi Tony,
>                                 >
>                                 > Thank you very much - I found myself
>                                 nodding along in agreement with all
>                                 your points.
>                                 >
>                                 > I think I achieved my objective,
>                                 which was (in combination with Ed's
>                                 use-case draft) to start a
>                                 conversation to discover if there are
>                                 problems worth tackling here - and I
>                                 still think there are.
>                                 >
>                                 > Cheers,
>                                 >
>                                 > Rick
>                                 >
>                                 > P.S.  I wanted to try to avoid using
>                                 the word 'topology' so early in a
>                                 document - but I suppose this is the
>                                 IETF so I could have got away with it ;)
>                                 >
>                                 >> -----Original Message-----
>                                 >> From: Tony Li
>                                 [mailto:[e-mail]
>                                 <mailto:[e-mail]>] On
>                                 Behalf Of Tony Li
>                                 >> Sent: 24 October 2022 21:12
>                                 >> To: Rick Taylor
>                                 >> Cc:[e-mail]
>                                 >> Subject: Re: [Tvr] First draft of
>                                 problem statement
>                                 >>
>                                 >>
>                                 >> Hi Rick,
>                                 >>
>                                 >> Thank you for your draft, it’s a
>                                 good starting point.
>                                 >>
>                                 >> Some thoughts, in no particular order:
>                                 >>
>                                 >> Conventional routing protocols are
>                                 somewhat less binary than you seem to
>                                 >> imply.  You write:
>                                 >>
>                                 >> Changes to that
>                                 >> connectivity, such as the loss of
>                                 an adjacent peer, are considered to
>                                 >>   be exceptional circumstances that
>                                 must be corrected prior to the
>                                 >> resumption of data transmission.
>                                 >>
>                                 >> In reality, of course, forwarding
>                                 continues as best it can. Alternate
>                                 routes get
>                                 >> computed as quickly as is
>                                 reasonably possible and forwarding
>                                 continues. Link
>                                 >> loss is a fault, to be sure, but is
>                                 sadly not exceptional or an error in
>                                 any way.
>                                 >> This is primarily an issue of tone.
>                                 >>
>                                 >> There has been some work done to
>                                 handle planned link (and node) outages.
>                                 >> These have been operationally
>                                 driven and to date don’t have a lot of
>                                 >> management plane automation, but
>                                 the techniques exist. Management sets
>                                 >> the metric on the link to a very
>                                 high value, effectively infinity, and
>                                 traffic is
>                                 >> diverted away from the link.
>                                 Automating this would be one possible
>                                 >> improvement that we could take on.
>                                 >>
>                                 >> You write that protocols assume:
>                                 >>
>                                 >> The individual nodes in a network
>                                 do not move around.
>                                 >>
>                                 >> I think that the physical
>                                 positioning of the nodes is not an
>                                 issue. What matters
>                                 >> is the topology. If you put a
>                                 network on a fleet of ships and you
>                                 move around
>                                 >> and the topology stays connected,
>                                 it’s not an issue.  When the topology does
>                                 >> change, then yes, that’s an issue.
>                                 Routing protocols do react to topology
>                                 >> changes and they do not expect a
>                                 topology to remain static.
>                                 >>
>                                 >> They DO make an inherent assumption
>                                 about the rate of topology changes.
>                                 >> Specifically, they are making the
>                                 assumption that the topology is
>                                 sufficiently
>                                 >> stable that it is efficient and
>                                 worthwhile to disseminate information
>                                 about the
>                                 >> topology change.  If the rate of
>                                 topology change is extreme, then the
>                                 cost of
>                                 >> flooding and distributed
>                                 computation may not be efficient.
>                                 >>
>                                 >> Moore’s law has been very kind to
>                                 us. The cost of doing path computation has
>                                 >> become almost irrelevant. True, the
>                                 algorithms are still O(n log n), so
>                                 scale is
>                                 >> an issue, but modern processors
>                                 have kept up reaonably well. Path
>                                 >> computation is not an event to be
>                                 feared.
>                                 >>
>                                 >> Modern forwarding practices have
>                                 also made path computation less
>                                 >> disruptive. When there is a link
>                                 failure, there can be precomputed fast
>                                 reroute
>                                 >> paths that will take over the paths
>                                 with little or no forwarding loss. 
>                                 The use of
>                                 >> ‘make before break’ techniques also
>                                 allow us to make new path computation
>                                 >> decisions without noticeable loss.
>                                 >>
>                                 >> One of the concerns that I have
>                                 that doesn’t seem to be addressed is about
>                                 >> link liveness and path computation
>                                 in the face of scheduled uptimes.
>                                 >> Specifically, can we be assured
>                                 that a link will appear on schedule?
>                                 Or do we
>                                 >> wait until proof of liveness before
>                                 directing traffic down the link? The
>                                 former
>                                 >> seems highly optimistic and
>                                 potentially disruptive. Section 4.2 seems
>                                 >> unnecessarily pessimistic. Our
>                                 operational experience has caused us to be
>                                 >> cautious about connectivity gains,
>                                 especially due to flapping circuits.
>                                 If those
>                                 >> can be addressed in a particular
>                                 environment, there is no reason that link
>                                 >> creation cannot be handled as
>                                 expeditiously as link failure.
>                                 >>
>                                 >> BGP does not require a global
>                                 recomputation of topology. Which is a very
>                                 >> good thing, as it has never
>                                 converged. :-)
>                                 >>
>                                 >> I agree that having an Adjacency
>                                 Schedule is a very good thing. Does it
>                                 really
>                                 >> need to be in the routing protocol?
>                                 I’m not convinced. It seems like this is
>                                 >> something that should be delivered
>                                 by the management plane. I’ll say it once
>                                 >> again: the IGP is not a dump truck.
>                                 >>
>                                 >> Regards,
>                                 >> Tony
>                                 >>
>                                 >>
>                                 >>
>                                 >>
>                                 >>> On Oct 24, 2022, at 11:17 AM, Rick
>                                 Taylor <[e-mail]>
>                                 >> wrote:
>                                 >>>
>                                 >>> Hi All,
>                                 >>>
>                                 >>> Right up against the deadline, I
>                                 have publish a very early Problem
>                                 >>> Statement draft at:
>                                 >>>
>                                 https://datatracker.ietf.org/doc/draft-taylor-tvr-prb-stmt/
>                                 <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-taylor-tvr-prb-stmt%2F&data=05%7C01%7Cmbeck%40utk.edu%7C49d9bf78dcd44c5a706408dab8f215b9%7C515813d9717d45dd9eca9aa19c09d6f9%7C0%7C0%7C638025647161452860%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=k84xSCnC2TMuvqIJXAZada8ZLP58ojrrFojmxMRe4tg%3D&reserved=0>
>                                 >>>
>                                 >>> Please feel free to read and
>                                 comment, and I'm happy to use it as a
>                                 basis
>                                 >>> for discussion at IETF-115.
>                                 >>>
>                                 >>> Cheers,
>                                 >>>
>                                 >>> Rick
>                                 >>>
>                                 >>> --
>                                 >>> Tvr mailing list
>                                 >>>[e-mail]
>                                 >>>
>                                 https://www.ietf.org/mailman/listinfo/tvr
>                                 <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftvr&data=05%7C01%7Cmbeck%40utk.edu%7C49d9bf78dcd44c5a706408dab8f215b9%7C515813d9717d45dd9eca9aa19c09d6f9%7C0%7C0%7C638025647161452860%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BF80EPuPMeKX9hiConu%2BDSl%2BMdZ11wxdxTMIRmwroiw%3D&reserved=0>
>                                 >
>                                 > --
>                                 > Tvr mailing list
>                                 >[e-mail]
>                                 >
>                                 https://www.ietf.org/mailman/listinfo/tvr
>                                 <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftvr&data=05%7C01%7Cmbeck%40utk.edu%7C49d9bf78dcd44c5a706408dab8f215b9%7C515813d9717d45dd9eca9aa19c09d6f9%7C0%7C0%7C638025647161452860%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BF80EPuPMeKX9hiConu%2BDSl%2BMdZ11wxdxTMIRmwroiw%3D&reserved=0>
>
>                             --
>                             Tvr mailing list
>                             [e-mail]
>                             https://www.ietf.org/mailman/listinfo/tvr
>                             <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftvr&data=05%7C01%7Cmbeck%40utk.edu%7C49d9bf78dcd44c5a706408dab8f215b9%7C515813d9717d45dd9eca9aa19c09d6f9%7C0%7C0%7C638025647161452860%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BF80EPuPMeKX9hiConu%2BDSl%2BMdZ11wxdxTMIRmwroiw%3D&reserved=0>
>
>                         --
>                         Tvr mailing list
>                         [e-mail]
>                         https://www.ietf.org/mailman/listinfo/tvr
>                         <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftvr&data=05%7C01%7Cmbeck%40utk.edu%7C49d9bf78dcd44c5a706408dab8f215b9%7C515813d9717d45dd9eca9aa19c09d6f9%7C0%7C0%7C638025647161452860%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BF80EPuPMeKX9hiConu%2BDSl%2BMdZ11wxdxTMIRmwroiw%3D&reserved=0>
>
>                     --
>                     Tvr mailing list
>                     [e-mail]
>                     https://www.ietf.org/mailman/listinfo/tvr
>                     <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftvr&data=05%7C01%7Cmbeck%40utk.edu%7C49d9bf78dcd44c5a706408dab8f215b9%7C515813d9717d45dd9eca9aa19c09d6f9%7C0%7C0%7C638025647161452860%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BF80EPuPMeKX9hiConu%2BDSl%2BMdZ11wxdxTMIRmwroiw%3D&reserved=0>
>
>                 --
>                 Tvr mailing list
>                 [e-mail]
>                 https://www.ietf.org/mailman/listinfo/tvr
>                 <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftvr&data=05%7C01%7Cmbeck%40utk.edu%7C49d9bf78dcd44c5a706408dab8f215b9%7C515813d9717d45dd9eca9aa19c09d6f9%7C0%7C0%7C638025647161452860%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BF80EPuPMeKX9hiConu%2BDSl%2BMdZ11wxdxTMIRmwroiw%3D&reserved=0>
>
>
>
>
>         --
>         Tvr mailing list
>         [e-mail]
>         https://www.ietf.org/mailman/listinfo/tvr
>