Re: [Tvr] First draft of problem statement

[Joel Halpern <[e-mail]>]

If your point is to say that both conventional routing and DTN should be 
able to make use of whatever logic / analysis / models TVR develops to 
represent time variation, that seems fine.  I understood your point as 
saying that TVR IP Routing should support storing packets in routers 
when there is no current connectivity. Routers essentially never store 
an undeliverable packet.  There are very good reasons for that.

Yours,

Joel

On 10/31/2022 12:11 PM, Jorge Amodio wrote:
>
> In essence unless you do circuit switching, all packet switching 
> networks store the packets in memory and you use routing information 
> to decide where to forward the packets, the issue is how long you 
> store them and if they carry routing data.
>
> DTN needs routing and it is a prime use case for TVR, particularly in 
> space communication applications.
>
> -Jorge
>
>> On Oct 31, 2022, at 9:55 AM, Joel Halpern <[e-mail]> wrote:
>>
>> 
>>
>> 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
>>>
>> -- 
>> Tvr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tvr
>