Minutes IETF111: rtgwg
minutes-111-rtgwg-00

IETF 111 RTGWG Meeting Minutes

Session I
Time:        12:00 - 14:00 PDT July 28, 2021

1. Meeting Administrivia and WG Update
   Chairs     (10 mins)

The chair Jeff went through the existing WG drafts. No objections from
the group.
Alvaro: Thanks to prior chair and the new chair.

2. AERO/OMNI and a Simple BGP-based Mobile Routing System for
   Aeronautical Telecommunications Network
   Fred Templin    (60 mins)

   https://datatracker.ietf.org/doc/draft-templin-6man-aero/
       establish short-cut in spanning tree
   https://datatracker.ietf.org/doc/draft-templin-6man-omni/
       9kb MTU over multiple underlay networks
   https://datatracker.ietf.org/doc/draft-ietf-rtgwg-atn-bgp/
        BGP based spanning tree

    Multiple IP hops as one Single Spanning tree link: OMNI link.

    Yingzhen:  the draft was in 6man, now on independent stream.
    Adrian:    Fred think it is hard to get traction in IETF. Therefore,
               better to be considered as independent stream. After
               some discussion, there is potential to take the work to
               IETF. Documents have the flags to indicate as
               independent stream. but I can definitely take off the
               flag for the WG to continue the discussion.
    Yingzhen:  the IPv6 portion doesn't belong to rtgwg, needs to be
               discussed at 6man.
    Jeff Trantsura: those are large documents, I don't see significant
               interests in routing.
    Linda Dunbar: Is there any routing interoperability needed among
               routers to enable the solution?
    Fred:      we use BGP overlay, another layer BGP instance with
               IPv6 native addresses. We can use the existing BGP.

3. SRv6 Midpoint Protection
   Xuesong Geng (10 mins)
   https://datatracker.ietf.org/doc/draft-chen-rtgwg-srv6-midpoint-protection/

Ketan Talaulikar: what is the difference between this draft and proxy
           forwarding?
XueSong:   totally different. The first draft is advertisement
           capability.
Ketan:     is this draft equivalent to SR-TE?
XueSong:   Yes, they are similar.
Ketan:     it would be helpful if you can clarify this in your draft.
Huaimo:    this one is focusing on SRv6, the one in Spring WG is more
           on SR-MPLS.
Ketan:     it is better to clarify them in the draft.
Jeff Tantsura: Chairs will discuss with SPRING Chairs to find the
           proper home. It doesn't make sense to have SR-MPLS in one
           place, and SR-v6 in another place.
YingZhen:  please send an email to the mailing list to have a
           discussion on this draft.

4. Extension of Transport Aware Mobility in Data Network
   Kausik Majumdar    (15 mins)

   https://datatracker.ietf.org/doc/draft-mcd-rtgwg-extension-tn-aware-mobility/

 Eduard V:  why not TCP?
 Kausik:    existing draft use UDP port.
 Eduard V:  you are asking functions from eNB.
 Kausik:    we are not getting from the UDP header, not from the GTP.
 Jie Dong:  My comments are similar, the pre-assumption is the UDP is
            used within 5G Core to indicate the Slice & Service Type.
            Currently this is described in the dmm document, what is
            the opinion of 3GPP on this approach?
Linda:      the IP data network can leverage the UDP ports used by
            Mobile section to ensure the end to end quality of the
            services.
Jie:        there might need some coordination with 3GPP so that the
            mobile network nodes will use UDP source port in this way.
Acee:       4 different options to doing it. FlowSpec is a default one.
            What is the relationship to SDWAN?
Kausik:     it gives the option to the operator more options. SDWAN
            might have secure tunnels. Need to maintain the security.
Jeff Tantsura: we probably need to clarify in the draft to show the
            mapping to 4G and 5G.

5. Computing Delivery in Routing Network
   Daniel Huang   (15 mins)
   https://www.ietf.org/id/draft-huang-computing-delivery-in-routing-network-00.html

   Jeff T: CoinRG is doing this work. Please reach out to them to discuss.

Session II
Time:        15:00 - 16:00 PDT July 29, 2021

1. Meeting Administrivia
Chairs     (5 mins)

2. Token Cell Routing Data Plane Concepts
Stewart Bryant    (20 mins)
https://datatracker.ietf.org/doc/draft-bcx-rtgwg-tcr/

Construct the packets as "tokens". Apply longest prefix match
engineers to invoke code points.
Key difference from Packet: non-linear

Jeff Haas:  what kind of network processing is required by this proposal?
Stewart:    it is essentially hybrid of IP and MPLS. So more powerful.
Jeff H:     what is the impact to firewall? you now introduce
            programming path that requires a lot of exceptions.
Stewart:    it is different from today's, but not too different.
            implicit parameters ordering rather than explicit ordering.
            Should be faster than TLV based.
Stewart:    TTL push to the preamble bits.

3. Functional Addressing (FA) for internets with Independent Network Address
Spaces (IINAS) Toerless Eckert   (15 mins)
https://datatracker.ietf.org/doc/draft-eckert-intarea-functional-addr-internets/

Eduard V: if node/links are inside, then need to find some route
Toreless: ways to get around this problem is to have ANYcast address.

4. Self-healing Networking with Flow Label
Alexander Azimov and Tom Herbert (20 mins)

Kireeti Kompella: first half of the routers, who is exchanging
Jeff Tantsura: The plan is providing routing and solution, reach out and
consider. I am looking forward to work in this domain.

Yingzhen: this is an example of you don't have a draft, but is meaningful for
the community.

****************************************************************
Chat Window History
****************************************************************

*** Wednesday Session ***

Juliusz Chroboczek
OAL?
12:17:33
Alvaro Retana
OMNI Adaptation Layer ???
12:18:14
Juliusz Chroboczek
Makes sense, thanks.
12:18:22
Tom Hill
192.88.99.0/24 is still pretty visible on the Internet
12:23:43
Erik Kline
reassigning 6to4 doesn't seem likely to me.
12:24:39
Juliusz Chroboczek
64 bytes from 192.88.99.1: icmp_seq=1 ttl=49 time=32.1 ms
12:24:45
Robert Moskowitz
Almost never can reuse, though in has been done...
12:25:10
Bob Hinden
I don't see anything about these addresses in this draft.
12:25:35
Robert Moskowitz
TBD?
12:25:47
Tom Hill
I thought I saw an email the other day that said 'this was done'?
12:26:25
Robert Moskowitz
note it...
12:27:20
oops wrong chat window :(
12:27:43
Juliusz Chroboczek
MTU adaptation refers to the fragmentation done by OAL, right? The encapsulated
IP packets used a fixed MTU? Is my understanding correct? 12:28:04 Eduard V yes
12:28:18 Juliusz Chroboczek Thanks. 12:28:29 Eduard V and this fragment is the
small one to be available in any situation 12:28:43 hence, 20+ fragments
possible 12:29:05 Jeff Tantsura Juliusz/Eduard - please discuss verbally in Q&A
part of the presentation 12:29:32 Eduard V all fixed size except last one
12:29:32 I have read it carefully. It is so big that does not make sense to
discuss in IETF meeting format. 12:30:16 Robert Moskowitz atn mailing list,
then? 12:31:58 Eduard V but who else spend a few days understanding this? I
have generated 20+ recommendations or improvements to Fred directly. 12:33:29
Jeff Tantsura that's a very good question 12:34:08 Adrian Farrel @Eduard Really
good that you took the time to provide feedback and recommendations. I know
Fred has been busy making updates to the documents. Would be useful to have
some feeling for the scope of the changes (you already gave a feeling for the
volume) because this helps us understand what the status of the work is
12:36:00 Eduard V My conclusion is: "I believe that it should be ADOPTED
because nothing else is competitive for the environment with Mobility
requirements on a big scale. Or else sooner or later, the mobility requirement
would be solved below IP by non-IP tools (like 3GPP did)." 12:37:21 The
solution is solid, just HUGE. 12:37:51 Erik Kline It currently requires changes
to IPv6 that were not adopted by 6man 12:38:12 Robert Moskowitz Boeing makes
BIG things... 12:38:12 Eduard V Erik, I do not understand what should be
changed. 12:38:56 Robert Moskowitz I think mostly due to "where are the users
for this?" 12:39:09 Boris Khasanov good question Robert 12:39:55 Eduard V It s
just L2 overlay cross everything with mobility support and all problems
resolved in the universe (42). 12:39:59 Robert Moskowitz And my conversations
within ICAO is why is this not moving in IETF? Are there technical problems????
12:40:10 Eduard V Only: nobody did read this. 12:40:38 Erik Kline Eduard:
TCP-over-ND and other ND-related changes, as proposed 12:40:58 Robert Moskowitz
The users don't come to the IETF. They expect tools they need already done.
Working with new stuff is hard for the community. They do seem to be adapting.
12:41:23 Eduard V Yes, ND expansion is big here. 12:41:47 Dino Farinacci And
that is a problem @BobM 12:41:53 Eduard V I do not understand what
"TCP-over-ND" means 12:42:09 Robert Moskowitz Why I have become really active
in ICAO TFSG. 12:42:33 ICAO = International Civil Aviation Authority and TFSG =
Trust Framework Study Group 12:43:25 Bob Hinden See slide 13, is proposes
adding TCP type flags to ND and a window. 12:43:34 Robert Moskowitz ICAO is a
UN agency, but older! 12:44:09 Bob Hinden BTW, The last time I checked a few
months ago, International Civil Aviation Organization (ICAO) was working on a
different solution than what Fred has proposed. I don't know that current
status. 12:44:18 Eduard V no. he has not expressed it properly. He called
"window" something else. I was trapped into this too but later understood that
it is not a window in reality (not for flow control). Just bad name. 12:45:03
Robert Moskowitz Lots being discussed. I am co-author of the GRAIN addressing
proposal. I thing GRAIN and OMNI can work together. 12:45:15 Bob Hinden Eduard:
I only know what I heard him say and what is on the slide. 12:45:43 Eduard V
yes, the document is not easy to understand. 12:46:15 As I said to Fred: needs
more structure and should be split into smaller pieces. 12:46:50 Juliusz
Chroboczek RFC 4380 is Teredo, what was the other RFC he cited? 12:47:23 Robert
Moskowitz All this part is outside my expertise. I have to count on others to
interact on the routing stuff. Probably reorg and dividing will help us all.
12:48:16 Adrian Farrel @robert Does "reorg" mean break up the doc? 12:48:52
Robert Moskowitz in part, or 'just' move sections around for smoother reading.
12:49:35 Eduard V just move would not help. 12:49:56 Robert Moskowitz If
sections can stand on their own, it could make sense for them all to be in a
single document. Too many documents have stalled other areas in IETF. 12:50:40
And too big a doc makes it so that nothing gets done until it is all done.
12:53:33 I want to hop over to madinas now. Catch you all around! 12:58:11
Ketan Talaulikar @ Xuesong, what is the relation of this draft with
draft-hu-spring-segment-routing-proxy-forwarding? Does it depend on the proxy
forwarding draft? 13:02:48 Yingzhen Qu @Ketan, can you please ask Xuesong after
her presentation? 13:03:37 Ketan Talaulikar ack 13:03:52 Eduard V why only UDP?
what would happen with TCP? 13:21:11 Jeff Tantsura GTP-U is IP/UDP, please ask
the authors 13:22:42 Eduard V Subscriber is identified by separate ID in GTP,
not by UDP 13:23:47 Jeff Tantsura TEID mapping proved to be complicated and
won't work in 5G 13:24:20 Eduard V then it is my problem 13:26:07 Linda Dunbar
It is expected that UPF can export the UDP ports of the GTP tunnels to be
exposed to the Data Network out of UPF 13:28:18 Uma Chunduri My Audio is not
working 13:29:13 UDP Src port used in the GTP encap. 13:29:41 No change
required on the mobile domain 13:29:56 Luay Jalil Is this proposal for the N6
interface only? 13:33:40 Uma Chunduri Yes, scope of this draft is on N6
13:33:59 Eduard V UDP port mappings better have in some 3GPP document as a
reference. It is probably a normative reference for this document. 13:35:19
Fred Templin Rolling back to the AERO/OMNI presentation, I am now just seeing
the traffic in the chat window. Anyone with questions remaining, please take
them to the rtgwg list and/or Cc: me directly at fltemplin@acm.org. Thank you.
13:36:37 Uma Chunduri SD WAN connection is for enterprise 5G scenario 13:37:26
Meaning all the 5G connections for an enterprise accessing service in the
cloud. Enterprise specific policies on N6 13:38:59 Jeff Tantsura 3GPP TS
23.501; System architecture for the 5G System (5GS) - a good reference 13:39:32
Jie Dong my understanding is this (UDP source port) may be one of the options
to map 3GPP SSTs or slices to transport network, there is a draft about the
network slice mapping in teas WG: draft-geng-teas-network-slice-mapping which
analyzed several options. That said, some coordination with 3GPP may be needed
on which field they will use to for the mapping 13:39:40 Boris Khasanov not yet
13:42:29 Tony Li We see infinite regressing browsers 13:43:22 Boris Khasanov
yeah :) 13:43:30 Tony Li Which is fun, but not informative 13:43:42 Dino
Farinacci and appears to be infinite ;-) 13:44:15 Tony Li Please go into
presentation mode 13:44:46 Kausik Majumdar @Jie, yes, UDP Source Port is simply
one option to map 3GPP SSTs or slices to the data network 13:45:25 Boris
Khasanov nope 13:45:26 Eduard V the presentation mode is on different screen
13:45:33 Cheng Li Triangle 2021 13:45:35 Dino Farinacci try the one at the top
13:45:49 he tapped on the bottom twice to no avail 13:45:58 Christian Hopps
This is why I like presenting all the slides. :) 13:46:11 Dhruv Dhody could be
multiple screens? 13:46:12 Christian Hopps Things have gone downhilll ever
since we left transparencies behind. :) 13:47:17 Tony Li Not to mention Russian
military hats. :-) 13:48:35 Eduard V 10 slides 13:50:50 Ketan Talaulikar i
still see the 2nd slide ... does indeed look like a multiple screens problem ?
13:50:54 Eduard V what is the current slide from presenter point of view?
13:51:41 Christian Hopps This happened the other day if it's "shared
application" insead of screen the presenter thing breaks sometimes with
poewrpoint 13:51:58 it's really sharing a window so it doesn't change to the
new presenter window 13:52:36 Dhruv Dhody Can the chair share? 13:53:21 Eduard
V push magnifing tool 13:54:54 everything is fine 13:55:41 Dino Farinacci
adrian's suggestion worked for me 13:55:41 click on magnify glass icon 13:55:53
Christian Hopps +1 13:56:13 Adrian Farrel Does anyone know whether this work
has been presented in COINRG? 13:57:19 Jeff Tantsura I don't think so 13:57:58
Cheng Li any draft of this work? 13:58:59 Yingzhen Qu
https://www.ietf.org/id/draft-huang…delivery-in-routing-network-00.html
13:59:21 Eduard V Meetecho, it is the second occasion when people could not
find how to see the rest of the slide (1/3). Please, change defaults - the
whole slide should be visible initially (do additional check for proportion).
Should not need to push magnifying glass for the slide that is 4:3 13:59:34
Meetecho Eduard: thanks for the feedback, we're aware of this and will probably
revisit this in the future

*** Thursday Session ***

Tony Przygienda
LU6.2 tessurected? ,-)
15:02:38
Yingzhen Qu
sorry for the wrong link: https://datatracker.ietf.org/doc/draft-bcx-rtgwg-tcr/
15:03:12
John Scudder
Is tessurection a portmanteau of resurrection and tesseract?
15:03:44
Tony Przygienda
Simple typo but thx for assuming the sophistication on my part *)
15:05:39
It happened parenthetically *) Got that one from Les
15:06:52
John Scudder
is it just me who's getting periodic dropouts from Stewart's audio?
15:07:06
Linda Dunbar
mine audio is good
15:07:22
Andrew Stone
audio has been solid here
15:07:25
Alexander Azimov
My audio is fine
15:07:25
John Scudder
TY
15:07:30
Robert Raszuk
Token cell looks like SRHv2 ... one more data plane source routing like as it
looks 15:07:46 Tony Li GRE source routes 15:08:19 Robert Raszuk Yup except
perhaps (but nit sure) a bit smaller ... Like ATMGRE all in one 15:08:49 Tony
Li Now you did it, that's the IETF equivalent of Godwin's law. 15:09:28 Jeffrey
Haas As someone who has familiarity with both the BSD implementation of regexec
and older knowledge of sendmail.cf, I'm having bad flashbacks. 15:09:28 Robert
Raszuk It seems to me that for some reason many people are so focused on
reinventing data plane instead of using control plane signaling in a bit more
novel ways 15:11:03 Tony Li We seem to want the data plane to be a bit more
complicated and less of the skinny point in the stack. 15:12:06 Jeffrey Haas ^
15:12:14 there are places that may be nice. security apparatus, for example.
15:12:34 Jeff Tantsura hmmm.... how do you justify more expensive hardware?
15:12:47 Eduard V parsing buffer should be for the whole packet, not 128B as it
is not. 15:13:09 Tony Li Hardware is free. We have SDN, so we no longer need
hardware. 15:13:19 Eduard V for some platforms 15:13:25 Robert Raszuk LOL
15:13:29 IMHO one day will get real optical switching ingress -- WAN -- egress
where control plane will be programming the switching on a per application
basis. Till that happens technology wise will keep seeing data plane mangling
on and on 15:16:13 Gyan Mishra kind of reminds me of atm fixed cells -blast
from the past :) 15:16:30 Tony Przygienda ATM silicon was simple even simpler
than IP module queuing then 15:17:23 Adrian Farrel @robert - bring back fiber
to the desktop 15:17:35 Antoine Fressancourt The length of each seemingly fixed
size cell is variable, which is a great difference 15:17:36 Tony Przygienda
today IP queuing is more complex than ATM 😀 15:17:53 Adrian Farrel So, Stewart
has invented TLVs? 15:17:58 John Scudder Furthermore the headers are headers
(or whatever he called them), not cells. 15:17:58 Robert Raszuk @Adrian .. well
was not thinking that far 15:18:00 Tony Li What we should have learned was that
optimizing the hardware didn't really matter. 15:18:16 Yes, this smells like a
TLV based dataplane. 15:18:50 Tony Przygienda Replace IP packets by WASM code 😃
15:18:58 Jeffrey Haas So, failed processing of tokens results not in ICMP, but
an ABEND cell? 15:19:47 Tony Li Actually, that would be an improvement as it
could be signed. 15:21:11 Eduard V Programmability is on the hype now. Here is
the biggest programmability. 15:21:13 Gyan Mishra back to the mainframe
days...where is my punch card 15:21:25 Tony Przygienda 1MB MTU with it 15:21:53
Robert Raszuk Did he say no TTL propagate no ICMP TTL Expired ? 15:25:02 Tony
Przygienda Nah we just realistic since we build and suffer at scale 😅 15:26:34
Tony Li Yes. The control plane has to have absolute and correct information
without error. This seems challenging. 15:27:05 TLVs are not an insult. They
are easy to deal with in hardware. 15:27:36 Alexander Clemm @TonyP: Why 1 MB
MTU? Token Cells are compact and you don't need many to express powerful
functionality. This is not general-purpose code but special-purpose "labels"
15:28:06 Tony Przygienda But you put lots of packets together afaiu 15:28:38
That will crimp your style already 15:28:57 Eduard V LISP is capable to deal
with shorter addresses 15:30:27 inside overlay 15:30:37 Alexander Clemm Look at
the examples: forwarding+ioam+service level objective/qos = 3 cells... not
prohibitive... 15:30:47 Tony Przygienda Jumping around in a packet is very
expensive if you don’t fit into scratchpad already and if you start to saturate
your bus with random jumping stuff slows down massively 15:31:23 i admit I
followed only loosely I’ll look up the draft 15:31:42 Stewart Bryant Yes, a
base system is no more complex than SR and in the case of SRv6 a lot smaller.
15:31:43 Dino Farinacci NSAPs can support shorter addresses 15:31:54 Tony
Przygienda Do NOT get me started on SRv6 😀 15:32:09 Stewart Bryant However
unlike SR you can have per segment parameters (if that make sense in the
application), for example instrumenting a segment 15:33:38 Robert Raszuk @TonyP
- Are you saying SRv6 does not solve all of the problems ??? :) 15:33:57 Tony
Przygienda Unfortunately it doesn’t but network programming does 🙃 15:34:27
Adrian Farrel @Stewart. Did you think about the cost/benefit? Obviously, it is
hard to nail the possible future benefits, but you should have several in mind.
On the other hand, the cost of developing new protocols, developing new
hardware, and deploying new protocols should be factorisable 15:34:59 Stewart
Bryant @Adrian - not done an economic analysis - at this stage just thinking
outside the protocol box to see what is possible 15:36:15 Acee Lindem @Adrian -
The token cell proposal is already generating revenue. At least for some...
15:36:16 Tony Przygienda I love this meetecho for the jaundiced cynicism 😉
normally you had to crowd the back of the room for that 15:37:40 Adrian Farrel
@Stewart. While I understand the value of talking to the routing community
about this, I am struggling to see it as IETF work *at*this*stage* 15:37:41
Acee Lindem @Tony - You know I'd expect the same ;^) 15:38:48 Stewart Bryant
@Adrian The title says "concept" 15:38:49 Tony Przygienda Hmmm, the Uber NAT ?
15:39:52 Stewart Bryant As I said, whist this was originally designed as a
candidate MPLS2, it is also an interesting way of building extension headers
15:40:17 Robert Raszuk Nope .. we have name for it - Carrier Great NAT 15:40:23
Grade 15:40:43 Tom Hill HyperGlobalComputMegaNAT? 15:41:08 Acee Lindem I must
admit that I haven't read these drafts but at least at 10,000 feet it appears
there may be opportunity for a merger as they seem to have similar goals.
15:41:30 Jeffrey Haas @stewart we're clearly hitting an inflection point to
carry source routing, meta data, and some level of "instructions". 15:41:49
John Scudder @acee given they're both research projects it seems a bit
premature to talk about mergers 15:42:10 Jeffrey Haas A bit of Toerless'
presentation is about the need for namespaced networks. 15:42:48 Toerless
Eckert @jeffrey: Interesting. is there some specific work to be found in IETF
under that term ? Seems there are lo of buzzwords.. 15:47:31 Jeffrey Haas
@toerless Not specifically that I'm aware of. Looked at a different way, the
issue is how could you have nested site-local scoped networks 15:48:34 end user
stacks will likely be dumb. so, how do you hand out addresses and set up
routing so embedded networks can interact with each other and eventually public
networks 15:49:20 Robert Raszuk @toerless Maybe you have already considered
this but to me the natural way to solve your problem would be with decoupling
locator from ID and adding overlay hierarchy. Flat networking in your case
looks not very attractive 15:50:35 Toerless Eckert @robert: Loc/Id is so
encumbered with perceptions, so i was avoiding that terminoloy. But yes: the
address within a network is a scoped identifier, and the rest of he address is
a locator program with steering inside or across name spaces 15:51:56 Jeffrey
Haas bingo 15:52:19 Robert Raszuk But you lack overlay hierarchy 15:52:22
Toerless Eckert @jeffrey: in something like a manufacturing plant, its all
manually configured before the plant goes live. In somethin like an enterprise
network i would reuse dns rewrite coupling. I have a reference to a 1999 cisco
configuration guide vom yakov rekhter as a fund reference in the draft.
15:53:15 @jeffrey: lots of other options too. 15:53:48 Tony Przygienda Good
preso 15:53:55 John Scudder Very 15:54:07 Keyur Patel yep 15:54:12 Tony
Przygienda I knew the stuff was around but first preso cleanly laying it out
incl Linux hacks 15:54:57 Robert Raszuk @toerelss Hint: I have been playing
with https://www.zerotier.com/ for the last few months. You build global flat
LANs (as many as you like) with /16 v4 each just for yourself in less then 15
sec per node. Except one bug I found - solid ! 15:55:09 It shows up as new
interface on router, pc, linux, nas ... you name it 15:55:49 Jeff Tantsura
planning to progress it here as informational, there's huge gain for everyone
running DC fabrics 15:56:22 Tony Przygienda Even wider 15:57:00 The state full
stuff is more generic 15:57:18 Tom Herbert The Anycast problem is not specific
to flow label modulation, any routing change that affects a flow could cause
similar problems 15:57:27 Jeff Tantsura yes 15:57:38 Tony Przygienda Yeah 😃 IP
cannot really do any cast 😊 15:58:10 Toerless Eckert Any good protocol has a
single packet anycast->unicast resolution step 15:58:24 Robert Raszuk Aren't
more and more real services moving to UDP these days (ex Quic) ? 15:58:39
Toerless Eckert RFC7450 for example ;-)) 15:58:50 Robert Raszuk for WAN at
least 15:58:51 Tony Przygienda Or rather statefull transport is accident
waiting to happen 15:59:01 Toerless Eckert if unicast transports don't do this,
too bad for them ;-) 15:59:07 Linda Dunbar @Tony Przygienda: Why IP can't do
ANYCAST? it has been in practice 15:59:15 Tony Przygienda Properly 15:59:26
anycast should have been a range 15:59:38 Tom Herbert Even more generally, any
mechanism that assume consistent routing for a transport flows, e.g. firewalls,
load balancers, etc. is susecptible to these problems. 15:59:40 Toerless Eckert
Linda: as i said, the recommendations do say i think what i said. Single packet
exchange resolution 15:59:41 Tony Li To be more specific, anycast and
connections are incompatible. Any routing change can easily disrupt things.
16:01:37 Stateless anycast is a non-issue. 16:01:59 Robert Raszuk 100% 16:02:05
Toerless Eckert if you don't need load balancing, prioritycast is a safe option
16:02:21 Tony Przygienda Back to DNS balancing folks 😀 16:03:58 Kireeti
Kompella thanks, Alex!