Chairs: Jeff Tantsura (jefftant.ietf@gmail.com)
Yingzhen Qu (yingzhen.ietf@gmail.com)
WG Page: https://datatracker.ietf.org/group/rtgwg/about/
Materials: https://datatracker.ietf.org/meeting/116/session/rtgwg
Chairs (10 mins)
=============================================
=============================================
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-qos-model/
Aseem Choudhary (10 mins)
No questions at the end of the presentation.
=============================================
=============================================
https://datatracker.ietf.org/doc/draft-liu-rtgwg-sr-protection-considerations/
Yisong Liu / Changwang Lin (10 mins)
Jeff Tantsura: What's your plan for this document? You listed all
protection techniques.
YingZhen: The draft is informational. It doesn't seem like you need
any extension
Weiqiang: the draft is about deployment of protection. all the
components have been discussed in the relevant groups. This draft is
only for information only.
Greg Mirsky: Slide #6: it is not clear what is the purpose of using
BFD session. BFD doesn't provide information about the locator SID,
it only verifies the forwarding path. I see it is over complicating
the OAMs
Jeff T: you can add some deployment considerations, when to use
which protection technology.
Weiqiang: we give the full picture of the all possible solutions.
not necessarily all of them are needed. some operators might only
need a subset. We will optimize the OAM. We think the document is
mature enough. We would like WG adoption.
https://datatracker.ietf.org/doc/draft-sheng-rtgwg-overlay-routing-requirement/
Hang Shi / Cheng sheng (10 mins)
Jeff T: you can use BGP for multicast, which has been there for many
years. Deployment of BIER is non trivial, and it's not supported by
silicon. What you described is vanilla SDWAN deployment for years,
looking forward to your protocol enhancement. it is not clear on
what you want to do. What is your next step?
Shi Hang: This is a requirement document. We are looking for
feedback and see if there are interests to collaborate. If so, we
will propose solution based on this requirement.
Tony P: The BIER BGP extension draft is under WGLC in IDR. If you
need any changes, please go to the relevant WGs to propose the
extension.
https://datatracker.ietf.org/doc/draft-zhou-rtgwg-sinc/
Signaling In-Network Computing operations (SINC) deployment
considerations
https://datatracker.ietf.org/doc/draft-zhou-rtgwg-sinc-deployment-considerations/
Zhe Lou (20 mins)
Adrian Farrel: wearing my CATS chair hat. I try to see the
difference between this and CATS. I see this as overlay as well, but
it's on path computation between two end points. It is similar to
SFC. CATS is about A-> B, and B does the calculation. CATS is about
which B to use and how to get to it.
Zhe: Correct. We try to define what is within the network.
=======================================================
Chairs (5 mins)
=============================================
=============================================
https://datatracker.ietf.org/doc/draft-trossen-rtgwg-rosa/
Dirk Trossen (15 mins)
David Lamparter: Extension Header needs clarification, maybe for
next presentation.
Dirk: you can find some technical details in section 7.
Aijun Wang: SAR needs to have a full table, no? How does it get the
information?
Dirk Trossen: Problem is understood but the routing table is limited
to the services a ROSA domain serves, thus not ALL services of the
Internet.
Aijun: ICNRG has some work going on but not depending on IP network.
Dirk: This one is to run over IP network.
https://datatracker.ietf.org/doc/draft-mcbride-rtgwg-bgp-blockchain/
Dirk Trossen (10 mins)
David Lamparter: All of the use cases have existing authorities that
control the topic at hand. Applying distributed consensus into that
is entirely useless.
Dirk Trossen: Trying to do permissioned DCS, not permissionless.
Q Misell: The cryptographic parts would require buy-in from e.g.
RIRs, have you been in contact with them?
Dirk Trossen: Still trying to figure out, need to facilitate
discussion somehow.
Andrew Alston: (personal) Answer to facilitating discussion: take
this to the IRTF. Too early, not even vaguely ready for
standardization, it's a research topic, better suited to IRTF.
Rüdiger Volk: Not seeing a direction what this is trying to tackle,
kitchen sink of problems that are raised once in a while by people
using BGP. Better cut down to specific problems. Possible cyclic
dependency with the network operating itself.
Dirk Trossen: ACK on Andrew's comment, will be taking this there.
Jeff T: speaking for myself. I support to get this to IRTF than
IETF.
https://datatracker.ietf.org/doc/draft-li-rtgwg-protocol-assisted-protocol/
Zhen Tan (10 mins)
Greg Mirsky: Characterization of problems only, no
notification/propagation of the failure information?
Zhen Tan (ZT): Protocol for gathering information on a device. It
helps to locate problems on the internet.
Greg Mirsky: Will devices keep some history log of events? (ZT: Yes)
How long?
Zhen Tan: Vendor dependent
Greg Mirsky: So, possible data will already be gone when operator
looks at it? (ZT: Yes) Notification would allow data to be stored
elsewhere.
Zhen Tan: We have notifications, like in use case #2. There will be
pre-configurations about sending notifications.
Aijun Wang: Protocol already knows reason for failure, what is the
benefit of having a separate protocol?
Zhen Tan: This does not need to keep another connection. PASP uses
UDP, the connection is on demand.
Aijun Wang: OK, need to understand reasons protocol itself can't do
this. is PSAP a on-demand protocol?
Zhen Tan: yes.
Adrian Farrel: You said RSVP, did you mean RSVP-TE? (ZT: Yes) This
might not be as applicable, RSVP-TE already has mechanisms for
collecting and propagating fault information, e.g. RFC 4873.
Zhen Tan: Goal is to have one way to get the information for all
protocols, otherwise hard to gather information.
Dmitry Afanasiev (20 min)
Tony Przygienda: Add path will cause massive path hunting, you need
this (tunneling?) You need to shout everything off, it's a broadcast
domain. Dynamic routing will be too slow, had that discussion
before. Shifting traffic based on congestion is a viable thing,
outside the realm of building a routing protocol that can keep up.
Doable? Yes, look at DAR (dynamic adaptible routing), was looking at
previous traffic, statistic on success. Works stunningly well. For
dragonfly, when the network grows big, you will have to tunnel to
keep 3-hops, then you will have to broadcast it and recompute.
Flooding & broadcasting approach versus reactive shifting flows
around. Reactive might be better to keep up.
Dimitry Afanasiev: Using VRFs rather than Tunnels, but yes. Adaptive
routing works in milliseconds.
Tony Przygienda: Amorphous Broadcast domain?
Tianji Jiang: Reminiscent of previous work 15 ears ago by Brocade,
L2 was done using trill, has that been looked at?
Jeff Tantsura: A lot of development happening on this topic
recently, some of it needs to happen at IETF.
https://datatracker.ietf.org/doc/html/draft-li-rtgwg-tte-00
Colby Barth (15 mins)
Greg Mirsky: This is to be monitored on a link level, not path
level? (CB: yes) Detection of congestion happens on egress to link,
action is supposed to be taken by ingress (upstream node)?
Colby Barth: Action is to be taken at the point of (local) repair,
that would otherwise act. Congestion is detected on a node's
outgoing interface, which also serves as the repairing node.
Greg Mirsky: So, monitoring outgoing interface, and taking action on
that. Not monitoring incoming queue, rather outgoing. (CB: yes) Not
taking notification from sources of traffic? (CB: Yes.) Action is
local, so effect overall on other flows cannot be considered, right?
Colby Barth: Yes, only flows transiting the affected node can be
considered. Not attempting to come up with a global fix.
Himanshu Shah: This is doing TI-LFA on a congested outgoing link,
that has been done before. Isn't this just a local implementation
that doesn't need an IETF specification?
Colby Barth: Absolutely correct, this is an informational draft,
it's a local node decision.
Himanshu Shah: What happens to other ongoing traffic, won't this
make things worse elsewhere?
Colby Barth: The example uses TI-LFA & tunnels, but other mechanisms
can be used. We call it TTE tunnels in the draft.
Himanshu: e2e tunnels are precalculated, better switched to those
then using ti-lfa.
Zhenbin Li: for TE tunnels, if you change in the middle, will this
cause packets out of order?
Colby Barth: Are you asking about this causing out of order packets?
(Yes)
Colby Barth: Typically the hashing algorithms should be flow based
which should alleviate problems.
Tony Li: Delay change is more significantly and will cause
congestion control impact. There is performance impact.
Jeff Tantsura: Other similar approaches suffer a lot from their
locality of action and may cause downstream congestion. Adding some
non-local decision might help.
https://datatracker.ietf.org/doc/draft-guo-ffd-requirement
Framework of Fast Fault Detection for IP-based Networks
https://datatracker.ietf.org/doc/draft-wang-ffd-framework
Haibo Wang (20 Mins)
Greg Mirsky: Terminology - mechanism used isn't failure detection,
more about failure notification? Using other mechanisms, e.g. BFD,
to detect defect? what you described is about propagating the
information in management plane.
Haibo Wang: Yes, other mechanisms in use in parallel, but also don't
want to run heavyweight things on endpoints.
Greg Mirsky: Motivation is the large delay in discovery (>10s)?
Haibo Wang: It's based on keep-alives. In some scenarios it's much
longer, 5-15 seconds, or 15 mins.
Greg Mirsky: Hints to me that there's some OAM mechanism missing. It
seems to me not a good design.
Zhenbin Li: Overlap with CATS working group, coordination?
David Black: For an unconverged failure, how do you detect that the
failure is unconverged or converged? Network examples on slides are
simple and obvious - how would determination that a failure is
unconverged be made for a more complex network such as the dragonfly
networks described in item 6 earlier in the meeting?
(Communication issues at this point. To continue on list.)
===========================================================
============================================================
https://datatracker.ietf.org/doc/draft-li-apn-problem-statement-usecases/
https://datatracker.ietf.org/doc/draft-li-apn-framework/
Zhenbin Li/Shuping Peng (10 mins)
Hongyi Huang/Qiangzhou Gao (5 mins)
presentation skipped, not enough time
Louis Chan
00:18:57
For ROSA, is there development requirement for client application?
David Lamparter
00:24:45
There seems to be no note-taker, I've hopped in but I'm a bit
multitasking-limited as I have comments to make too :)
David Lamparter
00:24:59
(or is someone taking notes outside the pad?)
Jeff Tantsura
00:25:32
David - hope you could do it
David Lamparter
00:26:31
I'll try my best. Would still appreciate if you could ask the room if
someone else wants to share the load.
David Lamparter
00:27:24
https://notes.ietf.org/notes-ietf-116-rtgwg?edit
Andrew Alston
00:36:27
I cannot see how this is vaguely ready to look at in terms of
standardization - I can see how someone may wanna try and do some
research on this in the irtf - maybe
Yingzhen Qu
00:39:57
https://notes.ietf.org/notes-ietf-116-rtgwg?both
Yingzhen Qu
00:40:19
Please contribute to notes
David Lamparter
00:40:37
(Uh. That comment was very disingenious. "Just asking questions. Can't
take questions to the IETF?" … you asked your question, you just didn't
like the answer. I'll point this out to Dirk after the session.)
Anthony Somerset
00:47:42
MD5 is not considered secure anymore surely?
Jeff Tantsura
00:48:37
for quite some time
Joel Halpern
00:49:33
This PASP thing seems to be addressing an already multiply-solved
problem.
David Lamparter
00:54:59
The agenda copied into notetaking pad doesn't match the room… I assume
the agenda in the notetaking pad wasn't updated for some rescheduling
Yingzhen Qu
00:59:18
@David. you're right, I got the presentation sequence wrong, this is
supposed to be #6. Sorry about that
David Lamparter
01:00:18
OK, no problem, I was just confused in the notes for a moment :)
Hesham ElBakoury
01:07:24
When sinc will be presented?
Yingzhen Qu
01:08:25
@Hesham, SINC was presented on Monday
Greg Mirsky
01:20:50
voice is breaking. Perhaps not using video feed might help
John Scudder
01:21:20
Audio seems better now. I assume it was affecting everyone and not just
those of us onsite?
David Black
01:21:35
Yes, affected me - remote.
Jeff Tantsura
01:23:44
me too
Tony Li
01:30:48
There's no signaling at all. Nothing to interoperate.
David Black
01:33:33
Still have an opportunity to misorder when an in-progress flow is
switched to another path.
Tony Li
01:34:58
Misordering is more likely when deactivating a prefix. You're moving a
flow from a presumably suboptimal path back to an optimal one.
Tony Li
01:35:22
In any case, ordering and latency are possible issues ANY time we change
the routing table.
Shaofu Peng
01:36:53
Hi Tony, In the absence of a central orchestration of controller, when a
node in the network implement local path switch, they cannot perceive
the impact on how much traffic will be affected, which may lead to
congestion on a link in the new path. Of course, it is exactly difficult
to learn how much traffic will be affected, but if we have that
knowledge, that will be more perfect.
Jeff Tantsura
01:38:31
@Tony - you might consider using a similar strategy as with adaptive
routing/DLB and move the flow only if the interpacket gap is large
enough not to cause reordering, it is somewhat less of an issue in the
WAN (perceptionally) than in DC, but still something to think about
Tony Li
01:38:54
No argument. One of the more intensive ways of using this technique is
also to monitor per-prefix traffic levels and decide to select prefixes
to balance bandwidth utilization.
Tony Li
01:39:35
@Jeff we're not too worried about this, given that the alternative is
packet loss.
Tony Li
01:39:51
But we don't want to thrash, either.
Jeff Tantsura
01:40:09
absolutely, rebalancing usually yields better results than binary on/off
Shaofu Peng
01:40:42
IMO misorder is out the scope of this proposal...
Tony Li
01:44:44
It's not really out of scope. It's more that it's the lesser of two
evils. :-)
Shaofu Peng
01:48:32
Agree, I just think that it is another local behavior, similar to LFA,
TI-LFA， and previously, we have not raised any concerns about the
disorder of these local behaviors. This issue is addressed by other
technology.
David Lamparter
01:54:58
I'm incredibly confused [by the discussion, not the problem David Black
describes], not sure what to put in the notes here.
John Scudder
01:56:13
I think David's point is very well-taken. If this problem (insofar as I
understand what the speaker is trying to do!) were easy, it would
already have been fixed. If there are low-hanging fruit special cases,
then identify them and make the case that they're worth addressing, but
I don't think that's been done.
Jeff Tantsura
01:56:52
+1 John