[{"author": "Lou Berger", "text": "do we have an in room delegate?
", "time": "2022-03-24T09:00:01Z"}, {"author": "Darren Dukes", "text": "Clear presentation Loa, thanks.
", "time": "2022-03-24T09:12:41Z"}, {"author": "Greg Mirsky", "text": "Carrying telemetry information in the data packet is optional. One can use, for example, IOAM Direct Export mode of IOAM Trace Option.
", "time": "2022-03-24T09:20:15Z"}, {"author": "J\u00e1nos Farkas", "text": "Is #4 about IEEE 802.1 TSN or IETF DetNet?
", "time": "2022-03-24T09:21:30Z"}, {"author": "J\u00e1nos Farkas", "text": "Note that the home of Time-Sensitive Networking is IEEE 802.1: https://1.ieee802.org/tsn/
", "time": "2022-03-24T09:23:56Z"}, {"author": "Ketan Talaulikar", "text": "So the use-cases, seem to be coming from teas, detnet, spring, ippm, sfc, ... wgs. Are we going to turn this into a joint meeting for all of them? :-)
", "time": "2022-03-24T09:24:15Z"}, {"author": "Greg Mirsky", "text": "It is based on https://datatracker.ietf.org/doc/html/draft-stein-srtsn-00
", "time": "2022-03-24T09:24:21Z"}, {"author": "Ketan Talaulikar", "text": "Or this is just mainly MPLS wg thing with others reviewing and providing inputs?
", "time": "2022-03-24T09:24:57Z"}, {"author": "Ketan Talaulikar", "text": "@stewart, so we can just have pals wg to just get notified of documents so it can review ?
", "time": "2022-03-24T09:26:23Z"}, {"author": "Darren Dukes", "text": "The problem is Stewart's mic
", "time": "2022-03-24T09:26:31Z"}, {"author": "J\u00e1nos Farkas", "text": "I'd suggest to use something else, e.g., \"time-aware\", to avoid collision with term already used by other SDO.
", "time": "2022-03-24T09:27:34Z"}, {"author": "Balazs Varga", "text": "Agree, calling #4 as TSN is very confusing. It is covering something similar but different than IEEE 802.1 TSN
", "time": "2022-03-24T09:29:38Z"}, {"author": "Balazs Varga", "text": "Very confusing
", "time": "2022-03-24T09:29:44Z"}, {"author": "Wim Henderickx", "text": "is it possible to get meetecho support i the room because we have a annoying echo here.
", "time": "2022-03-24T09:31:04Z"}, {"author": "John Scudder", "text": "I agree with J\u00e1nos -- anything that doesn't acronym to \"TSN\" would be better.
", "time": "2022-03-24T09:31:06Z"}, {"author": "John Scudder", "text": "Wim, are you still getting echo right now?
", "time": "2022-03-24T09:31:17Z"}, {"author": "John Scudder", "text": "I am almost certain the problem is at Stewart's end.
", "time": "2022-03-24T09:31:26Z"}, {"author": "Meetecho", "text": "Coming
", "time": "2022-03-24T09:31:41Z"}, {"author": "Nicolai Leymann", "text": "We all have an echo (also remote participants)
", "time": "2022-03-24T09:31:44Z"}, {"author": "John Scudder", "text": "He either needs to improve his headset setup (probably not achievable during the meeting) or be very diligent about muting himself.
", "time": "2022-03-24T09:31:47Z"}, {"author": "Wim Henderickx", "text": "@john, not sure but we wll test asap
", "time": "2022-03-24T09:31:51Z"}, {"author": "Wim Henderickx", "text": "we have someone in the meeting to help
", "time": "2022-03-24T09:32:04Z"}, {"author": "Ketan Talaulikar", "text": "@ john - +1
", "time": "2022-03-24T09:32:09Z"}, {"author": "Wim Henderickx", "text": "so hopefully we will resolve it asap
", "time": "2022-03-24T09:32:18Z"}, {"author": "Meetecho", "text": "We don't hear any echo in the remote stream
", "time": "2022-03-24T09:32:59Z"}, {"author": "Meetecho", "text": "Was it while another remote participant was unmuted too?
", "time": "2022-03-24T09:33:11Z"}, {"author": "John Scudder", "text": "Yes.
", "time": "2022-03-24T09:33:16Z"}, {"author": "John Scudder", "text": "Stewart.
", "time": "2022-03-24T09:33:18Z"}, {"author": "Lou Berger", "text": "chair DoS attack....
", "time": "2022-03-24T09:33:35Z"}, {"author": "Mach Chen", "text": ":grin:
", "time": "2022-03-24T09:33:48Z"}, {"author": "Ketan Talaulikar", "text": "C-DoS
", "time": "2022-03-24T09:33:59Z"}, {"author": "John Scudder", "text": "Probably not the first echo protocol Stewart has worked on.
", "time": "2022-03-24T09:34:23Z"}, {"author": "Meetecho", "text": "If it's echo generated by Stewart, I'm not sure there's much we can do, as we'd have to completely mute the local room when he speaks, going half duplex
", "time": "2022-03-24T09:36:07Z"}, {"author": "Lou Berger", "text": "not sure how that would help
", "time": "2022-03-24T09:36:34Z"}, {"author": "Meetecho", "text": "If we don't send audio to him, he can't bounce it back
", "time": "2022-03-24T09:37:17Z"}, {"author": "Lou Berger", "text": "ahh, but he's the session chair
", "time": "2022-03-24T09:37:33Z"}, {"author": "Meetecho", "text": "Yep, that's why I meant only do half duplex when he's talking
", "time": "2022-03-24T09:37:49Z"}, {"author": "John Scudder", "text": "Are we getting echo when only Stewart is speaking? I didn't think so. I thought it was when Stewart was unmuted and anyone else was speaking.
", "time": "2022-03-24T09:37:53Z"}, {"author": "Lou Berger", "text": "exactly
", "time": "2022-03-24T09:38:16Z"}, {"author": "Meetecho", "text": "Yes, by speaking I meant \"mic unmuted\", apologies for the confusion
", "time": "2022-03-24T09:38:28Z"}, {"author": "John Scudder", "text": "Stewart tells me unicast, that he'll try to exercise greater mute discipline. Hopefully that will be sufficient.
", "time": "2022-03-24T09:39:11Z"}, {"author": "Wim Henderickx", "text": "Do we all agree the ancillary data name can refers to both in-stack and post-stack? I personally feel it might be better to make it explicit -> ancillary data in-stack and ancillary data post -stack.
", "time": "2022-03-24T09:44:51Z"}, {"author": "J\u00e1nos Farkas", "text": "Note that Further Reroute may have acronym collision with Fast Reroute.
", "time": "2022-03-24T09:45:31Z"}, {"author": "Ketan Talaulikar", "text": "@ wim +1 - we do need that clarification explicitly
", "time": "2022-03-24T09:45:39Z"}, {"author": "Vishnu Beeram", "text": "It is \"No Further Fast Reroute\".. NFFRR is the acronym
", "time": "2022-03-24T09:46:43Z"}, {"author": "John Scudder", "text": "Yeah, that one concerns me less. TLA collisions will always be with us, it's when the TLA collision is between closely overlapping technologies, involving another SDO, that it's a serious problem.
", "time": "2022-03-24T09:47:34Z"}, {"author": "J\u00e1nos Farkas", "text": "I agree John. Thanks.
", "time": "2022-03-24T09:49:51Z"}, {"author": "J\u00e1nos Farkas", "text": "(I was misled by typo on the slide: \"No Further Reroute (NFRR)\")
", "time": "2022-03-24T09:53:48Z"}, {"author": "Bruno Decraene", "text": "I lost the audio. Is this just me?
", "time": "2022-03-24T09:59:38Z"}, {"author": "Ketan Talaulikar", "text": "@bruno yes
", "time": "2022-03-24T09:59:46Z"}, {"author": "John Scudder", "text": "yes, just you I'm afraid
", "time": "2022-03-24T09:59:46Z"}, {"author": "Bruno Decraene", "text": "thanks.
", "time": "2022-03-24T09:59:56Z"}, {"author": "Ketan Talaulikar", "text": "@Jags - if we get SPL then why would NPL be required. In other words, is the option for NPL being proposed if SPL is not available?
", "time": "2022-03-24T10:00:39Z"}, {"author": "Rakesh Gandhi", "text": "@Ketan - to show the encoding is generic and can be used with different methods of indicators
", "time": "2022-03-24T10:02:02Z"}, {"author": "Rakesh Gandhi", "text": "WG provides feedback to prefer one
", "time": "2022-03-24T10:02:33Z"}, {"author": "Ketan Talaulikar", "text": "@Rakesh, if the authors don't see anything new/special being provided by an NPL then I would suggest to just have the option of SPL. I agree the ELI/EL is a very good and complementary option.
", "time": "2022-03-24T10:03:56Z"}, {"author": "Rakesh Gandhi", "text": "@Ketan, acking
", "time": "2022-03-24T10:04:45Z"}, {"author": "Rakesh Gandhi", "text": "Opcode says HbH or E2E. We do not need to add two opcodes for HbH as it includes E2E
", "time": "2022-03-24T10:11:32Z"}, {"author": "Rakesh Gandhi", "text": "@Greg - ELI signaing extension for MEH is required. Encap node will not expose ELI/MEH on legacy node to avoid any packet drop issue.
", "time": "2022-03-24T10:14:03Z"}, {"author": "Greg Mirsky", "text": "@Rakesh I believe that we cannot guarantee that the new ELI would not be exposed at LSR that supports \"regular\" ELI interpretation
", "time": "2022-03-24T10:23:03Z"}, {"author": "Ketan Talaulikar", "text": "This is network programmability with limited bits ... constrained network programmability that can be done in a much simpler manner.
", "time": "2022-03-24T10:26:32Z"}, {"author": "Greg Mirsky", "text": "@Jeff T We thought that 16 SPLs is enough. Not.
", "time": "2022-03-24T10:30:21Z"}, {"author": "Rakesh Gandhi", "text": "@Greg, Encap node needs to always ensure that \"any SPL\" is not exposed on a node that does not support it to avoid dropping packets.
", "time": "2022-03-24T10:31:48Z"}, {"author": "Ketan Talaulikar", "text": "@Greg if these are user/deployment defined then they would go much farther. That is why I referred to limited network programmability
", "time": "2022-03-24T10:31:54Z"}, {"author": "Ketan Talaulikar", "text": "s/farther/further :-)
", "time": "2022-03-24T10:32:39Z"}, {"author": "Greg Mirsky", "text": "@Rakesh The encap node does its best but bad things happen. That is reality.
", "time": "2022-03-24T10:33:33Z"}, {"author": "Rakesh Gandhi", "text": "@Greg - and it is true for \"any SPL\", right?
", "time": "2022-03-24T10:34:32Z"}, {"author": "Greg Mirsky", "text": "@Rakesh True. But using a new SPL would not break ELI/EL
", "time": "2022-03-24T10:35:23Z"}, {"author": "Jie Dong", "text": "the terminology about network slice ID really need to be aligned...
", "time": "2022-03-24T10:37:24Z"}, {"author": "Vishnu Beeram", "text": "@Jie -- it will be aligned in the next rev.
", "time": "2022-03-24T10:38:35Z"}, {"author": "Jie Dong", "text": "@Pavan good to hear that
", "time": "2022-03-24T10:39:58Z"}, {"author": "Rakesh Gandhi", "text": "@Greg - New SPL can break forwarding if Encap node is not careful
", "time": "2022-03-24T10:40:07Z"}, {"author": "Greg Mirsky", "text": "@Rakesh What do you mean by \"break\"?
", "time": "2022-03-24T10:41:17Z"}, {"author": "Rakesh Gandhi", "text": "@Greg - If a node does not understand SPL, it may drop the packets when SPL is exposed
", "time": "2022-03-24T10:43:36Z"}, {"author": "Jie Dong", "text": "The exposure of SPL is a real problem we need to consider
", "time": "2022-03-24T10:44:51Z"}, {"author": "Rakesh Gandhi", "text": "@Jie: Agree
", "time": "2022-03-24T10:45:15Z"}, {"author": "Greg Mirsky", "text": "@Rakesh you mean it MUST drop the packet with the unknown label. That is what RFC 3031 tells. IMHO, that is better then an LSR misinterpreting ISD as a label
", "time": "2022-03-24T10:46:11Z"}, {"author": "Haoyu Song", "text": "@all: In the following MPLS session, we'll give an overview on MPLS extension header, please stay tuned. Thanks!
", "time": "2022-03-24T11:00:15Z"}, {"author": "Rakesh Gandhi", "text": "@Greg: I understand your point, but it is expected that the Encap node must add proper encap.
", "time": "2022-03-24T11:02:05Z"}]