[{"author": "Nitsan Dolev Elfassy", "text": "

Good morning

", "time": "2023-11-07T08:31:28Z"}, {"author": "Yingzhen Qu", "text": "

please help with the note taking: https://notes.ietf.org/notes-ietf-118-rtgwg

", "time": "2023-11-07T08:38:09Z"}, {"author": "Tony Li", "text": "

Bruno's mic is very low

", "time": "2023-11-07T08:40:44Z"}, {"author": "Pascal Thubert", "text": "

For the sake of memory the ARC solution to FRR includes uloop avoidance as part of the design

", "time": "2023-11-07T08:42:02Z"}, {"author": "Martin Horneffer", "text": "

Full support to Bruno\u2018s statement!
\nIP-FRR is useful even without explicit strategies to avoid uLoops.

", "time": "2023-11-07T08:43:27Z"}, {"author": "Stewart Bryant", "text": "

@Pascal yes, but I think the right way here is an operational considerations section to alert the reader to the issue and the mitigations - and removal of the reference to the specific uloop proposal that it currently contains

", "time": "2023-11-07T08:58:08Z"}, {"author": "Daniel Bernier", "text": "

@Linda why is this draft standards track and not informational ?

", "time": "2023-11-07T08:58:23Z"}, {"author": "Daniel Bernier", "text": "

ie SDWAN draft ?

", "time": "2023-11-07T08:58:33Z"}, {"author": "Stewart Bryant", "text": "

There is probably a case for all RFC have an operational considerations section similar to a security considerations section

", "time": "2023-11-07T08:59:05Z"}, {"author": "Adrian Farrel", "text": "

@stewart. Do you \"operational\" or \"manageability\"?

", "time": "2023-11-07T09:00:26Z"}, {"author": "Antoine Fressancourt", "text": "

@Linda Dunbar when and where will the draft be discussed from security perspective ? I didn't get it

", "time": "2023-11-07T09:00:52Z"}, {"author": "Stewart Bryant", "text": "

@Adrian - isn't manageability a subset of operations

", "time": "2023-11-07T09:10:32Z"}, {"author": "Darren Dukes", "text": "

@stewart @Adrian, I think operational is more accurate given RFC5706.

", "time": "2023-11-07T09:10:39Z"}, {"author": "Darren Dukes", "text": "

that's a question not a statement :)

", "time": "2023-11-07T09:11:15Z"}, {"author": "Stewart Bryant", "text": "

I think it was a rhetorical question

", "time": "2023-11-07T09:12:08Z"}, {"author": "Adrian Farrel", "text": "

@stewart. I'd refer you to RFC 5706 (which has gone somewhat out of fashion, and was never mandated), and to RFC 6123 (which is how one RTG working group handles the question)

", "time": "2023-11-07T09:12:50Z"}, {"author": "Stewart Bryant", "text": "

@Adrian 6123 is historuc

", "time": "2023-11-07T09:15:37Z"}, {"author": "Adrian Farrel", "text": "

Yes, and?

", "time": "2023-11-07T09:16:13Z"}, {"author": "Stewart Bryant", "text": "

and we do not normally recommend historic actions in new work

", "time": "2023-11-07T09:18:20Z"}, {"author": "Adrian Farrel", "text": "

RTFM

", "time": "2023-11-07T09:18:30Z"}, {"author": "Daniel Bernier", "text": "

@nikangkang are you seeking a solution ? or want to make it a standard ?

", "time": "2023-11-07T09:19:37Z"}, {"author": "Dan Voyer", "text": "

historical events or consider baseline, where you have lesson learned taking action moving forward should always based on where you are coming from

", "time": "2023-11-07T09:20:23Z"}, {"author": "Dan Voyer", "text": "

*are considered

", "time": "2023-11-07T09:20:42Z"}, {"author": "Tony Li", "text": "

I'm getting a significant amount of background noise. From other mics?

", "time": "2023-11-07T09:23:46Z"}, {"author": "Daniel Bernier", "text": "

@nikangkang FYI it might be a question of implementation details since some of the REQs on your draft can/are related on the automation/orchestration mechanisms used and/or SF specifics implementations

", "time": "2023-11-07T09:23:59Z"}, {"author": "Antoine Fressancourt", "text": "

@Tony I think it i sfro th epresenter's office space

", "time": "2023-11-07T09:24:26Z"}, {"author": "Daniel Bernier", "text": "

@nikangkang as an FYI most of your REQs we have already solved and deployed through implementation specifics

", "time": "2023-11-07T09:25:06Z"}, {"author": "Jeff Tantsura", "text": "

@Tony - this is not local

", "time": "2023-11-07T09:25:14Z"}, {"author": "Tony Li", "text": "

Lesson: go to a conference room to present... :-(

", "time": "2023-11-07T09:25:32Z"}, {"author": "Antoine Fressancourt", "text": "

... If they are available

", "time": "2023-11-07T09:25:54Z"}, {"author": "Jeff Tantsura", "text": "

@Daniel - would you please send your detailed comments to the list, ideally with references
\nThanks!

", "time": "2023-11-07T09:26:22Z"}, {"author": "Linda Dunbar", "text": "

because there are new IANA assignment is needed:
\nIANA is requested to assign a new GENEVE Option Class from the IETF Review range as shown below:
\n Option
\n Class Description Assignee/Contact Reference

\n
\n

tbd Multi Segment SD-WAN IETF [this document]

\n

IANA is requested to create a registry as below with the initial values shown in the Multi Segment SD-WAN Geneve Option Class registry group:

\n

Registry: Multi Segment SD-WAN Sub-TLVs
\n Assignment Policy: IETF Review
\n Reference: [this document]

\n

Sub-TLV Type Description Reference
\n ------------ ---------------------- ---------------
\n 0 Reserved
\n 1 SD-WAN Endpoint [this document]
\n 2 SD-WAN Originator [this document]
\n 3 SD-WAN Egress GW [this document]
\n 4 Multi SD-WAN-HMAC [this document]
\n 5-254 Unassigned
\n 255 Reserved

", "time": "2023-11-07T09:26:53Z"}, {"author": "Daniel Bernier", "text": "

@jeff yes I will

", "time": "2023-11-07T09:27:20Z"}, {"author": "Daniel Bernier", "text": "

@Linda what if one would want to do this without GENEVE encap ?

", "time": "2023-11-07T09:28:01Z"}, {"author": "Antoine Fressancourt", "text": "

@Daniel maybe you would use SRv6 HMAC ?

", "time": "2023-11-07T09:28:37Z"}, {"author": "Linda Dunbar", "text": "

What options are you proposing?

", "time": "2023-11-07T09:30:11Z"}, {"author": "Daniel Bernier", "text": "

@antoine I have my preferences but there are a myriad of ways to do this already implemented so, I'd do a problement statement rfc

", "time": "2023-11-07T09:30:21Z"}, {"author": "Daniel Bernier", "text": "

@linda before @jeff tells me so, I'll document on the list :grinning_face_with_smiling_eyes:

", "time": "2023-11-07T09:30:41Z"}, {"author": "Jeff Tantsura", "text": "

;-)

", "time": "2023-11-07T09:31:00Z"}, {"author": "Linda Dunbar", "text": "

The GENEVE is proposed because GENEVE is used by most Cloud Providers

", "time": "2023-11-07T09:31:00Z"}, {"author": "Yingzhen Qu", "text": "

The side meeting for SR TI-LFA will be Wednesday (11/8) 17:00-18:00, Location: Palmovka 1/2
\nWebex Link:
\nhttps://ietf.webex.com/meet/sidemeetingietf2

", "time": "2023-11-07T09:31:18Z"}, {"author": "Antoine Fressancourt", "text": "

@Linda when and where will the draft be discussed from security perspective ? I didn't get it

", "time": "2023-11-07T09:32:01Z"}, {"author": "Linda Dunbar", "text": "

I am waiting for Sec AD for the appropriate group to discuss

", "time": "2023-11-07T09:34:16Z"}, {"author": "Antoine Fressancourt", "text": "

ok

", "time": "2023-11-07T09:34:24Z"}, {"author": "Antoine Fressancourt", "text": "

Thanks. and thanks for your work, very interesting

", "time": "2023-11-07T09:35:12Z"}, {"author": "nikangkang", "text": "

@Daniel Bernier We
\n are seeking solutions and can you send your solution to my email?

", "time": "2023-11-07T09:40:24Z"}, {"author": "Daniel Bernier", "text": "

yes

", "time": "2023-11-07T09:40:36Z"}, {"author": "Gyan Mishra", "text": "

@TI-LFA Look forward to the side meeting discussion. I think the direction is clear from todays discussion, reiterating what Sasha had mentioned on ML that section 6 of the TI-LFA draft defines micro loop avoiding options for the post convergence repair path is the key, thus decoupling any reference to the uLoop draft makes sense. Also a possible operator considerations section maybe a good idea as well. Cheers.

", "time": "2023-11-07T09:41:34Z"}, {"author": "Stewart Bryant", "text": "

@Gyan - agree. Also think that it should be clearer why Post convergence path is preferred but note that is is not required and that such a decision is a matter for the PLR

", "time": "2023-11-07T09:45:44Z"}, {"author": "Gyan Mishra", "text": "

@Stewart, I agree that should be made clearer as that is a critical point for operators as to why the post convergence path due to loopfree-ness but not required. Good points for operational considerations section.

", "time": "2023-11-07T09:48:17Z"}, {"author": "Louis Chan", "text": "

@Steward My question would be: would it allow different uLoop approaches in the same network since it is pure PLR(s) decision.

", "time": "2023-11-07T09:48:20Z"}, {"author": "Jeff Tantsura", "text": "

@roland - KIRA-Networking-2022

", "time": "2023-11-07T09:51:31Z"}, {"author": "Stewart Bryant", "text": "

Sort of . Some of the loop methods are mutually compatible, but some are not.

", "time": "2023-11-07T09:55:05Z"}, {"author": "Louis Chan", "text": "

If this is the case, TI-LFA and uloop should be separate.

", "time": "2023-11-07T09:55:52Z"}, {"author": "Stewart Bryant", "text": "

... but the margin of the chat os a bit small to list the compatibilities

", "time": "2023-11-07T09:56:06Z"}, {"author": "Sasha Vainshtein", "text": "

@Louis: Micro-loop avoidance has to be done by all nodes in the network, not just by the PLRs. Even in the case of a link/node failure, no action done by teh PLRs will not prevent micro-loops happening before traffic destination reaches the PLR. And, of course, recovery of a link/node simply does not cause any TI-LFA actions = but may as readily result in micro-loops as a failure:upside_down:

", "time": "2023-11-07T09:56:15Z"}, {"author": "Louis Chan", "text": "

@Sasha, I mean for one failure, there could be more than one PLR in the chain linked to the same failure.

", "time": "2023-11-07T09:57:18Z"}, {"author": "Stewart Bryant", "text": "

Are yes Sasha we need to remind people of the good news case

", "time": "2023-11-07T09:57:21Z"}, {"author": "Stewart Bryant", "text": "

@Louis - that is the SRLG case - unrelated failures are considered too hard and normally the recommendation is to abandon all hope

", "time": "2023-11-07T09:58:33Z"}, {"author": "Louis Chan", "text": "

before it reaches the PLR next to the failure.

", "time": "2023-11-07T09:58:46Z"}, {"author": "Louis Chan", "text": "

one PLR node could just choose to drop the packet if it is a remote failure...that could be an simple uloop avoidance method too.

", "time": "2023-11-07T09:59:55Z"}, {"author": "Stewart Bryant", "text": "

@Louis please clarify your scenario

", "time": "2023-11-07T09:59:59Z"}, {"author": "Stewart Bryant", "text": "

@Sasha you ar not quite right - incremental metric - can be unitary action by the PLR, but all others require all ingress nodes to execute a uloop method, OFIB and new labels requires all nodes to take action

", "time": "2023-11-07T10:02:22Z"}, {"author": "Dan Voyer", "text": "

are we doing tomorrow's side meeting for Ti-LFA here or we keep this for tomorrow ? I have few things to unpack on this and just trying to see when ?

", "time": "2023-11-07T10:04:14Z"}, {"author": "Daniel Bernier", "text": "

@daniel huang I will post on the list BUT I would have you look at networkservicemesh.io that does exactly what you are proposing with no ties to specific encapsulation

", "time": "2023-11-07T10:04:33Z"}, {"author": "Stewart Bryant", "text": "

@Dan we should do it tomorrow

", "time": "2023-11-07T10:05:57Z"}, {"author": "Antoine Fressancourt", "text": "

@Daniel Bernier Maybe I browsed too quickly but the least I can say is that NSM is not very explicit on the format used to convey packets (IP) in the mesh.

", "time": "2023-11-07T10:09:03Z"}, {"author": "Daniel Bernier", "text": "

@antoine exactly it will depend on the vWIRE implementation

", "time": "2023-11-07T10:10:18Z"}, {"author": "Daniel Bernier", "text": "

not forcing oine

", "time": "2023-11-07T10:10:25Z"}, {"author": "Daniel Bernier", "text": "

one (typo)

", "time": "2023-11-07T10:10:37Z"}, {"author": "Antoine Fressancourt", "text": "

Good from them to give people choice, but maybe having an opinion would be good too

", "time": "2023-11-07T10:13:51Z"}, {"author": "Eduard V", "text": "

HPC (and AI training) demands latency in the range of a few microseconds. It already affects the time of calculations.

", "time": "2023-11-07T10:14:22Z"}, {"author": "Jeff Tantsura", "text": "

latency is not directly related to failures and remediations

", "time": "2023-11-07T10:16:36Z"}, {"author": "Eduard V", "text": "

True, not directly. But probably affects anyway.

", "time": "2023-11-07T10:17:52Z"}, {"author": "Sasha Vainshtein", "text": "

@Stewart: You are right about incremental cost.

", "time": "2023-11-07T10:18:21Z"}, {"author": "Jeff Tantsura", "text": "

while HPC (and inference to see degree) are latency censitive while training is much more jitter censitive

", "time": "2023-11-07T10:19:30Z"}, {"author": "Sasha Vainshtein", "text": "

@Louis: AFAIK, TI-LFA assumes (indirectly?) that all links are P2P, so each failed link has exactly two PLRs.

", "time": "2023-11-07T10:19:49Z"}, {"author": "Sasha Vainshtein", "text": "

Have to drop now.

", "time": "2023-11-07T10:20:40Z"}, {"author": "Louis Chan", "text": "

@Sasha, usually yes, 2. But due to diff time of convergence in control plane, other routers in the chain could be getting into uloop. and these routers could be pseudo-PLR(s) too.. my understanding.

", "time": "2023-11-07T10:22:47Z"}, {"author": "Dmitry Afanasiev", "text": "

@Jeff And very bandwidth sensitive - there are few very fat flows and we want them spread over links very uniformly otherwise tail latency for reduce phase grows significantly

", "time": "2023-11-07T10:23:58Z"}, {"author": "Dmitry Afanasiev", "text": "

so just any kind of shuffling flows or adaptation is not enough for training workloads

", "time": "2023-11-07T10:24:51Z"}, {"author": "Jeff Tantsura", "text": "

there's no flow to begin with...

", "time": "2023-11-07T10:25:05Z"}, {"author": "Dmitry Afanasiev", "text": "

ok, vectors )

", "time": "2023-11-07T10:25:25Z"}, {"author": "Dmitry Afanasiev", "text": "

so we are talking about vector transfer completion time

", "time": "2023-11-07T10:26:13Z"}]