[{"author": "Joel Halpern", "text": "Thank you.<br/>", "time": "2022-03-25T11:30:03Z"}, {"author": "Meetecho", "text": "Was the audio better?<br/>", "time": "2022-03-25T11:30:42Z"}, {"author": "Joel Halpern", "text": "Yes.<br/>", "time": "2022-03-25T11:30:48Z"}, {"author": "Meetecho", "text": "Did you get any echo?<br/>", "time": "2022-03-25T11:30:50Z"}, {"author": "Bruno Decraene", "text": "Thanks.<br/>", "time": "2022-03-25T11:30:57Z"}, {"author": "Jorge Amodio", "text": "Good audio<br/>", "time": "2022-03-25T11:30:59Z"}, {"author": "Bruno Decraene", "text": "No echo<br/>", "time": "2022-03-25T11:31:04Z"}, {"author": "Meetecho", "text": "Ack, thanks!<br/>", "time": "2022-03-25T11:31:04Z"}, {"author": "Tom Hill", "text": "Noice<br/>", "time": "2022-03-25T11:31:29Z"}, {"author": "\u00c9ric Vyncke", "text": "Shame that SPRING was not on 21st of March ;-)<br/>", "time": "2022-03-25T11:32:27Z"}, {"author": "Joel Halpern", "text": ":-)<br/>", "time": "2022-03-25T11:32:54Z"}, {"author": "Ketan Talaulikar", "text": "@Eric is it now SUMMER already?<br/>", "time": "2022-03-25T11:32:57Z"}, {"author": "Darren Dukes", "text": ":)<br/>", "time": "2022-03-25T11:33:36Z"}, {"author": "Tony Li", "text": "I second the proposal for changing the WG name.<br/>", "time": "2022-03-25T11:33:40Z"}, {"author": "Ketan Talaulikar", "text": "@TonyL ... you think we need more heat? ;-)<br/>", "time": "2022-03-25T11:34:14Z"}, {"author": "Ted Hardie", "text": "@Ketan How about a beach and frosty drinks?<br/>", "time": "2022-03-25T11:34:44Z"}, {"author": "Tony Li", "text": "Right now, yes. It's positively chilly here in CA. Relatively, of course. :)<br/>", "time": "2022-03-25T11:35:07Z"}, {"author": "Ketan Talaulikar", "text": "+1 for frosty drink; not so sure of beach where I am at. Feels like summer already :-(<br/>", "time": "2022-03-25T11:35:39Z"}, {"author": "Darren Dukes", "text": "Can anyone else hear the echo?&nbsp;&nbsp;Is that the room mics or someone else?<br/>", "time": "2022-03-25T11:37:05Z"}, {"author": "~~dhruv~~dhody~~", "text": "Yeah In Bangalore it is HOT 34 C (94 F) and its march! <br/>", "time": "2022-03-25T11:37:18Z"}, {"author": "Tom Hill", "text": "No echo in the room so far as we know<br/>", "time": "2022-03-25T11:37:29Z"}, {"author": "\u00c9ric Vyncke", "text": "Slight echo in the room (but I am next to a loud speaker)<br/>", "time": "2022-03-25T11:37:49Z"}, {"author": "Joel Halpern", "text": "@Darren yes, there is a faint echo - probably the room microphones because we asked them to raise the room volume.<br/>", "time": "2022-03-25T11:37:51Z"}, {"author": "Tom Hill", "text": "Ah, yes. Bruno is a little louder than Joel and Andrew were, too.<br/>", "time": "2022-03-25T11:38:17Z"}, {"author": "Ted Hardie", "text": "Maybe Andrew is muted?<br/>", "time": "2022-03-25T11:38:24Z"}, {"author": "Tony Li", "text": "Audio is cutting in and out.<br/>", "time": "2022-03-25T11:41:02Z"}, {"author": "Lars Eggert", "text": "in the room, too.<br/>", "time": "2022-03-25T11:41:11Z"}, {"author": "Tom Hill", "text": "I think that was Thomas<br/>", "time": "2022-03-25T11:41:27Z"}, {"author": "Lars Eggert", "text": "got better here now<br/>", "time": "2022-03-25T11:41:27Z"}, {"author": "Tom Hill", "text": "Seems to have resolved<br/>", "time": "2022-03-25T11:41:30Z"}, {"author": "Andrew Alston", "text": "I presume that the references to c-sid refer equally to g-sid?<br/>", "time": "2022-03-25T11:48:00Z"}, {"author": "Ted Hardie", "text": "This says adopt by OPSAWG at 113; was it adopted there?<br/>", "time": "2022-03-25T11:49:00Z"}, {"author": "Beno\u00eet Claise", "text": "Ted: No decision at this point in time<br/>", "time": "2022-03-25T11:49:21Z"}, {"author": "Ted Hardie", "text": "@Benoit&nbsp;&nbsp;Thanks.<br/>", "time": "2022-03-25T11:49:32Z"}, {"author": "Erik Kline", "text": "the meaning of segments left when c-sids are present deviates from the 8200 semantic definition<br/>", "time": "2022-03-25T11:49:34Z"}, {"author": "Ketan Talaulikar", "text": "@Erik, looking at the draft the Segment Left seems to refers to what is in the SRH<br/>", "time": "2022-03-25T11:51:33Z"}, {"author": "Francois Clad", "text": "@Andrew the same considerations would be applicable to both NEXT-C-SID and REPLACE-C-SID (aka G-SID)<br/>", "time": "2022-03-25T11:51:35Z"}, {"author": "Darren Dukes", "text": "The same is true for Binding SIDs Erik, there should be no interpretation of the SID or its behavior IMO. Just transport the list and leave it to the consumer of the data to understand the SIDs<br/>", "time": "2022-03-25T11:51:37Z"}, {"author": "Ted Hardie", "text": "lides-113-spring-mpls-extension-header-encodings/<br/>", "time": "2022-03-25T11:51:40Z"}, {"author": "Meetecho", "text": "I've imported it now<br/>", "time": "2022-03-25T11:52:02Z"}, {"author": "Bruno Decraene", "text": "thanks<br/>", "time": "2022-03-25T11:52:16Z"}, {"author": "Tom Hill", "text": "@meetecho May we have a slight adjustment to the levels in Grand Park 2? Louder microphones are causing some echo/mild deafening.<br/>", "time": "2022-03-25T12:05:51Z"}, {"author": "Tom Hill", "text": "(Remote attendees with microphones with high gain, that is)<br/>", "time": "2022-03-25T12:06:14Z"}, {"author": "Ketan Talaulikar", "text": "@Dhruv, this is more of an implementation thing IMHO. I don't think we have a protocol gap.<br/>", "time": "2022-03-25T12:06:29Z"}, {"author": "Meetecho", "text": "Tom, do you mean in the local room?<br/>", "time": "2022-03-25T12:07:06Z"}, {"author": "Ketan Talaulikar", "text": "@Dhruv, ack - likely on multiple PCE based solution there might be some gaps<br/>", "time": "2022-03-25T12:07:08Z"}, {"author": "Tom Hill", "text": "Yes @meetecho<br/>", "time": "2022-03-25T12:07:12Z"}, {"author": "Meetecho", "text": "We were asked to increase the volume of remote speakers<br/>", "time": "2022-03-25T12:07:15Z"}, {"author": "Meetecho", "text": "Because they were not audible enough<br/>", "time": "2022-03-25T12:07:22Z"}, {"author": "Tom Hill", "text": "You were, it needs some fine tuning<br/>", "time": "2022-03-25T12:07:23Z"}, {"author": "~~dhruv~~dhody~~", "text": "@ketan - agree for single PCE case not for inter-domain PCE case<br/>", "time": "2022-03-25T12:07:30Z"}, {"author": "Meetecho", "text": "Tuned the playout volume a bit, let me know if it helps<br/>", "time": "2022-03-25T12:09:45Z"}, {"author": "Tom Hill", "text": "@meetecho, thanks - hopefully that will reduce the maximum volume.<br/>", "time": "2022-03-25T12:10:22Z"}, {"author": "Cheng Li", "text": "I am thinking that do we have a requirements to deploy network like that. A option A solution seems very straightforward and easy to manage. Any way we will deploy a domain then another. So the service deployment Must have two steps. so in the first step a option A is already there.<br/>", "time": "2022-03-25T12:11:04Z"}, {"author": "Tom Hill", "text": "Remote attendees: please start with less microphone gain. We will tell you if you are too quiet :)<br/>", "time": "2022-03-25T12:11:59Z"}, {"author": "Ketan Talaulikar", "text": "@ Cheng, not sure that I follow your comment. Are you saying that underlay (transport) IW is not required?<br/>", "time": "2022-03-25T12:13:31Z"}, {"author": "Zhibo Hu", "text": "The goal of MPLS is to simplify forwarding and improve performance. Is the MPLS extension consistent with the original goal?<br/>", "time": "2022-03-25T12:13:39Z"}, {"author": "Jeff Tantsura", "text": "As the operator of one of the largest SR networks in the world, I sincerely hope to retire before I'd need to troubleshoot \"network like that\" :)<br/>", "time": "2022-03-25T12:13:40Z"}, {"author": "Tony Li", "text": "@Zhibo All of it is optional and far simpler than other, far more complex mechanisms to accomplish the same goals.<br/>", "time": "2022-03-25T12:14:55Z"}, {"author": "Cheng Li", "text": "@Ketan, yes. I mean we may not need that.<br/>", "time": "2022-03-25T12:16:43Z"}, {"author": "Zhibo Hu", "text": "@Tony Li .In fact, if it need to read the bottom-of-stack information hop by hop, it is not friendly to forwarding.<br/>", "time": "2022-03-25T12:16:44Z"}, {"author": "Cheng Li", "text": "Just go to SRv6 directly. If we update it step by step, then&nbsp;&nbsp;use option A<br/>", "time": "2022-03-25T12:17:14Z"}, {"author": "Joel Halpern", "text": "I hope I got back in sync on which slide he is discussing.<br/>", "time": "2022-03-25T12:17:20Z"}, {"author": "Tony Li", "text": "Most of the cases of bottom of stack data are for OAM.<br/>", "time": "2022-03-25T12:18:08Z"}, {"author": "Tony Li", "text": "The value add is in the functions that are embedded. E.g. slice identification.<br/>", "time": "2022-03-25T12:20:52Z"}, {"author": "Ketan Talaulikar", "text": "@ Cheng, not every operator has the luxury to upgrade everything to SRv6. Doing Option A is an option (called overlay/service IW) for some use-cases but for others like mobility (SRv6 at edge and existing MPLS domains in the middle).<br/>", "time": "2022-03-25T12:22:26Z"}, {"author": "Cheng Li", "text": "it looks like we may spend many years to design the whole set of what we have in IPv6, telemetry/IFIT/IOAM, HBH, DOH, TLVs, SFC with metadata,&nbsp;&nbsp;anycast.<br/>", "time": "2022-03-25T12:22:34Z"}, {"author": "Tony Li", "text": "The good news is that it can be done incrementally.<br/>", "time": "2022-03-25T12:23:02Z"}, {"author": "Cheng Li", "text": "I like MPLS, it is very classical, simple with goof forwarding performance.<br/>", "time": "2022-03-25T12:23:39Z"}, {"author": "Tom Hill", "text": "IMO it is a feature of SR-MPLS that does not include large amounts of metadata in the forwarding plane.<br/>", "time": "2022-03-25T12:23:53Z"}, {"author": "Cheng Li", "text": "but looks like it is getting complicated. sad to see that.<br/>", "time": "2022-03-25T12:23:59Z"}, {"author": "Tony Li", "text": "People are welcome to not use it if they don't want to.<br/>", "time": "2022-03-25T12:24:18Z"}, {"author": "Cheng Li", "text": "but I appreciate the effort the people have made to it. Thank you<br/>", "time": "2022-03-25T12:24:40Z"}, {"author": "Tony Li", "text": "Unfortunately, the industry (and IETF) seems to add complexity, not simplicity.<br/>", "time": "2022-03-25T12:24:48Z"}, {"author": "Jeff Tantsura", "text": "@tony - complexity sells :)<br/>", "time": "2022-03-25T12:25:37Z"}, {"author": "Tom Hill", "text": "*complexity IS sold :)<br/>", "time": "2022-03-25T12:25:51Z"}, {"author": "Yuya Kawakami", "text": "How about creating IPv6 VPN over the MPLS domain to forward SRv6 packets...? &gt;SRv6 at edge and existing MPLS domains in the middle<br/>", "time": "2022-03-25T12:26:07Z"}, {"author": "Tony Li", "text": "Yes, but at some point, you end up with complexity collapse, when it can no longer be operated and supported.<br/>", "time": "2022-03-25T12:26:10Z"}, {"author": "Boris Khasanov", "text": "@Tony, not always, yesterday you told about simplification, for example.<br/>", "time": "2022-03-25T12:26:30Z"}, {"author": "Tony Li", "text": "The whole point of this is to avoid the SRv6 overhead.<br/>", "time": "2022-03-25T12:26:31Z"}, {"author": "Tom Hill", "text": "@Yuya I believe that was an example in the interworking draft presented earlier.<br/>", "time": "2022-03-25T12:26:39Z"}, {"author": "Dan Voyer", "text": "in order to go to SRV6, you first need an IPv6 network and refreshing boxes to support SRv6 is not always easy. IPv6/SR-MPLS is a good transition for some part in the network while refreshing boxes for SRv6..<br/>", "time": "2022-03-25T12:26:52Z"}, {"author": "Tony Li", "text": "@Boris Does that mean that everyone will listen to me? :)<br/>", "time": "2022-03-25T12:26:59Z"}, {"author": "Boris Khasanov", "text": "@Tony, yesterday - many, IMO.<br/>", "time": "2022-03-25T12:27:31Z"}, {"author": "Ketan Talaulikar", "text": "@ Yuva, that is what was referred to - 6PE<br/>", "time": "2022-03-25T12:27:37Z"}, {"author": "Tony Li", "text": "@Boris Apparently we had different yesterdays. :)<br/>", "time": "2022-03-25T12:28:32Z"}, {"author": "Boris Khasanov", "text": ":)<br/>", "time": "2022-03-25T12:29:02Z"}, {"author": "Ketan Talaulikar", "text": "@Yuva, I meant that was exactly what one of the solution/design was in that interworking presentation<br/>", "time": "2022-03-25T12:29:03Z"}, {"author": "Jeff Tantsura", "text": "@dan, after you have got IPv6oSR-MPLS deployed and working, what would be the incentive to move to SRv6? I'd think that the choice to do one vs another should be done before<br/>", "time": "2022-03-25T12:29:29Z"}, {"author": "Tony Li", "text": "@Jeff You need more overhead in your network so you waste more bandwidth and have to buy more boxes.<br/>", "time": "2022-03-25T12:30:40Z"}, {"author": "Dan Voyer", "text": "@jeff, service programming for SRv6<br/>", "time": "2022-03-25T12:30:53Z"}, {"author": "Tom Hill", "text": "Which is an if, not a when<br/>", "time": "2022-03-25T12:31:18Z"}, {"author": "Tom Hill", "text": "IF you want to do network/service programming in your data plane.<br/>", "time": "2022-03-25T12:31:40Z"}, {"author": "Tony Li", "text": "Or, you can do it with MIAD.<br/>", "time": "2022-03-25T12:31:57Z"}, {"author": "Dan Voyer", "text": "@Tom, yes, as per your use cases and business drivers<br/>", "time": "2022-03-25T12:32:17Z"}, {"author": "Jeff Tantsura", "text": "@dan - what service? I do see interesting use cases in overlay, in underlay I need to move packets from A to B, and as soon as possible :)<br/>", "time": "2022-03-25T12:32:53Z"}, {"author": "Yuya Kawakami", "text": "@Ketan Thanks, I missed it<br/>", "time": "2022-03-25T12:35:03Z"}, {"author": "Dan Voyer", "text": "@Jeff, ah true, you can keep service programming for overlay services only - I was shooting what came to mind.<br/>", "time": "2022-03-25T12:35:15Z"}, {"author": "Jeff Tantsura", "text": "@tony - we have been supporting context labels since forever, just distribute context with a dumbtrack of the day (and 8277 allows label stack)<br/>", "time": "2022-03-25T12:37:16Z"}, {"author": "Tony Li", "text": "And MIAD is more knobs on top of that.<br/>", "time": "2022-03-25T12:39:17Z"}, {"author": "Jeff Tantsura", "text": "talking of complexity ;-0<br/>", "time": "2022-03-25T12:39:34Z"}, {"author": "Tony Li", "text": "I did not create the feature request. :)<br/>", "time": "2022-03-25T12:39:56Z"}, {"author": "Tom Hill", "text": "How are we doing on audio, folks?<br/>", "time": "2022-03-25T12:41:37Z"}, {"author": "Jeff Tantsura", "text": "locally - pretty good<br/>", "time": "2022-03-25T12:41:51Z"}, {"author": "Tony Li", "text": "Remote audio is excellent<br/>", "time": "2022-03-25T12:41:56Z"}, {"author": "Tom Hill", "text": "Excellent<br/>", "time": "2022-03-25T12:42:04Z"}, {"author": "Boris Khasanov", "text": "@Jeff - \"Navigating network complexity\" book :)<br/>", "time": "2022-03-25T12:42:06Z"}, {"author": "Zhibo Hu", "text": "Technology is developing in a spiral of complexity and simplification.<br/>", "time": "2022-03-25T12:42:22Z"}, {"author": "Boris Khasanov", "text": "Remotely audio is good too<br/>", "time": "2022-03-25T12:42:28Z"}, {"author": "Tom Hill", "text": "@meetecho last tweak seems to have much improved the experience, thank you.<br/>", "time": "2022-03-25T12:42:30Z"}, {"author": "Meetecho", "text": "Glad to be of help!<br/>", "time": "2022-03-25T12:42:44Z"}, {"author": "Jeff Tantsura", "text": "technology isn't developing passively, we are here to drive it (hopefully in the right direction)<br/>", "time": "2022-03-25T12:43:31Z"}, {"author": "Jie Dong", "text": "@Linda, what you mentioned is the mechanism for mapping 3GPP network slices to IETF network slices, there is a draft in TEAS: draft-geng-teas-network-slice-mapping<br/>", "time": "2022-03-25T12:43:44Z"}, {"author": "Jeff Tantsura", "text": "meetecho rules!<br/>", "time": "2022-03-25T12:43:47Z"}, {"author": "Tony Li", "text": "@Jeff Technology is driven by finance, not by intelligence.<br/>", "time": "2022-03-25T12:44:11Z"}, {"author": "Cheng Li", "text": "agree. LOL<br/>", "time": "2022-03-25T12:44:50Z"}, {"author": "Jeff Tantsura", "text": "@tony - hopefully there's an intersection of both ;-)<br/>", "time": "2022-03-25T12:44:53Z"}, {"author": "Jeff Tantsura", "text": "somewhere...<br/>", "time": "2022-03-25T12:45:01Z"}, {"author": "Zhenbin Li", "text": "@Linda <a href=\"https://datatracker.ietf.org/doc/draft-geng-teas-network-slice-mapping/\" rel=\"nofollow\">https://datatracker.ietf.org/doc/draft-geng-teas-network-slice-mapping/</a><br/>", "time": "2022-03-25T12:45:05Z"}, {"author": "Tony Li", "text": "That is 100% on you Jeff.<br/>", "time": "2022-03-25T12:45:07Z"}, {"author": "Jeff Tantsura", "text": "doing my best!<br/>", "time": "2022-03-25T12:45:25Z"}, {"author": "Zhibo Hu", "text": "@Jeff yes, when it's too complex, we push it toward simplification, and when it's too little functionality, we push it toward complexity.<br/>", "time": "2022-03-25T12:45:58Z"}, {"author": "Jeff Tantsura", "text": "@zhibo - an intelligent creature learns from past mistakes, not so keeps on repeating them<br/>", "time": "2022-03-25T12:47:19Z"}, {"author": "Zhibo Hu", "text": "22/5000 \u62fc\u97f3&nbsp;&nbsp;\u7ffb\u8bd1<br/>No, I think this is a benign development, not a repetition of mistakes.<br/>", "time": "2022-03-25T12:48:26Z"}, {"author": "Shraddha Hegde", "text": "There iOAM proposal for SR-MPLS. what is the difference between path tracing for SR-MPLS and the iOAM proposal?<br/>", "time": "2022-03-25T12:48:42Z"}, {"author": "~~dhruv~~dhody~~", "text": "I guess, just the claim that they are better!<br/>", "time": "2022-03-25T12:49:56Z"}, {"author": "Jeff Tantsura", "text": "@zhibo - not to any technology in particular, just a general statement<br/>", "time": "2022-03-25T12:51:23Z"}, {"author": "Pablo Camarillo", "text": "@Shraddha: Path Tracing tackles a different use-case, and as such the architecture differs. Path Tracing (due to the minimal dataplane design) can be implemented across most hardware in the datapath (at linerate without any coprocessor).<br/>", "time": "2022-03-25T12:52:10Z"}, {"author": "Shraddha Hegde", "text": "@pablo could you pls elaborate what is the difference in usecase from an operator perspective?<br/>", "time": "2022-03-25T12:53:44Z"}, {"author": "Justin Iurman", "text": "I agree with Greg. Not sure why they tackle different use cases. It looks like the only thing would be to define new \"compressed\" IOAM data fields to have something similar<br/>", "time": "2022-03-25T12:58:31Z"}, {"author": "Pablo Camarillo", "text": "@Justin: it is not only about compressed data. That is one important factor. But the way the header is designed helps on how many editing commands you need to support it. In Path tracing all the nodes do the same editing action (always shift and stamp).<br/>", "time": "2022-03-25T13:03:26Z"}, {"author": "Pablo Camarillo", "text": "@Shraddha: ECMP monitoring and troubleshooting with information collected on the datapath itself (no CPU, no OAM coprocessors or similar)<br/>", "time": "2022-03-25T13:04:08Z"}, {"author": "Justin Iurman", "text": "@Pablo fine, but so does IOAM. I don't really see a big difference in what you described for PT<br/>", "time": "2022-03-25T13:07:26Z"}, {"author": "Greg Mirsky", "text": "@Pablo IOAM DEX allows an operator use a local policy and export telemetry information directly to RC<br/>", "time": "2022-03-25T13:07:39Z"}, {"author": "\u00c9ric Vyncke", "text": "Feel sad that no presenters have turned on their video :-(<br/>", "time": "2022-03-25T13:08:05Z"}, {"author": "Tom Hill", "text": "Thomas did? :)<br/>", "time": "2022-03-25T13:08:29Z"}, {"author": "Greg Mirsky", "text": "Or one can use HTS to collect information along the path in the follow-up HTs packet. Without any limitation on the amount of data<br/>", "time": "2022-03-25T13:08:37Z"}, {"author": "Jim Guichard", "text": "@Eric that is because they are all in their pajamas ;-)<br/>", "time": "2022-03-25T13:08:57Z"}, {"author": "Darren Dukes", "text": "@eric too early/late/tired by friday :)<br/>", "time": "2022-03-25T13:08:57Z"}, {"author": "Cheng Li", "text": "all no camera in office...<br/>", "time": "2022-03-25T13:09:18Z"}, {"author": "\u00c9ric Vyncke", "text": "@Tom, indeed ! Kudos to @Thomas :birthday:<br/>", "time": "2022-03-25T13:09:24Z"}, {"author": "\u00c9ric Vyncke", "text": "@Jim, do you speak by personnal experience ? :-) (I did a couple of call in pyjamas to be honest)<br/>", "time": "2022-03-25T13:10:01Z"}, {"author": "Cheng Li", "text": "A f2f IETF meeting is attractive. Wouldn't wait for too long. has been 2 years and longer....<br/>", "time": "2022-03-25T13:10:23Z"}, {"author": "Tom Hill", "text": "The virtual meeting on Bangkok time was definitely in pyjamas<br/>", "time": "2022-03-25T13:10:28Z"}, {"author": "Jim Guichard", "text": "@Eric damn i am definitely assimilated as i forgot how to correct pyjamas correctly 8^)<br/>", "time": "2022-03-25T13:11:46Z"}, {"author": "Jim Guichard", "text": "@Eric *spell<br/>", "time": "2022-03-25T13:12:12Z"}, {"author": "Lars Eggert", "text": "so each hop would rewrite the udp payload and recompute the checksum?<br/>", "time": "2022-03-25T13:12:59Z"}, {"author": "Darren Dukes", "text": "@lars it appears so.<br/>", "time": "2022-03-25T13:13:55Z"}, {"author": "Ahmed Abdelsalam", "text": "@ Greg The postcard (i.e, HTS) and passport (i.e, Path Tracing) modes are two different ways of collecting packet path information from the network. The Path Tracing solution defined in this draft uses the passport mode. The original challenge of the passport mode is collecting the data from NPU, in the normal packet pipeline, at linerate. This challenge has been solved in Path tracing.<br/>Also on the HTS, how many postcards you would need to export to measure a network with&nbsp;&nbsp;X paths each of which has N hops... and will the node telemetry system scale for that ?<br/>I won't the controller scale which has to aggregate all of these packets to build a path compared to Path tracing .. which you have the path info in single packet collected from NPU at line rate<br/>", "time": "2022-03-25T13:14:28Z"}, {"author": "Justin Iurman", "text": "+1000 Greg<br/>", "time": "2022-03-25T13:18:18Z"}, {"author": "Haoyu Song", "text": "@Ahmed IOAM DEX uses the post card mode<br/>", "time": "2022-03-25T13:21:38Z"}, {"author": "Greg Mirsky", "text": "@Ahmed as was pointed out, updating IPv6 packet requires re-calculation of the checksum. That negatively impacts the accuracy of time measurement and smaller data space cannot help here. IMHO, separating data generation from data collection and transport is the better operational method<br/>", "time": "2022-03-25T13:22:09Z"}, {"author": "Haoyu Song", "text": "@Greg The draft needs to standardize an SRH flag bit and therefore it goes to SPRING and the intended status is STANDARD<br/>", "time": "2022-03-25T13:23:44Z"}, {"author": "Greg Mirsky", "text": "@Haoyu, you believe that there's a need for the flag. I don't see such need at all. IMHO, draft-ietf-ippm-ioam-ipv6-options solves IOAM encapsulation for all IPv6 cases, including SRv6<br/>", "time": "2022-03-25T13:25:29Z"}, {"author": "Boris Khasanov", "text": "Are there anyccccccvktdvullgveldrkitfkttitffdvkurjicrihdv<br/>", "time": "2022-03-25T13:25:31Z"}, {"author": "Ketan Talaulikar", "text": "the cat is back ;-)<br/>", "time": "2022-03-25T13:25:58Z"}, {"author": "Ahmed Abdelsalam", "text": "@Greg which checksum are you referring to ? There is no checksum in IPv6 header and we don't have any UDP here.<br/>", "time": "2022-03-25T13:26:17Z"}, {"author": "Boris Khasanov", "text": "@Ketan - yes :(&nbsp;&nbsp;2nd try: are there any implementations for SR Policy groups?<br/>", "time": "2022-03-25T13:26:44Z"}, {"author": "Murray Kucherawy", "text": "Cat, or OTP?<br/>", "time": "2022-03-25T13:28:03Z"}, {"author": "Ketan Talaulikar", "text": "@ Boris, I am aware of one<br/>", "time": "2022-03-25T13:28:15Z"}, {"author": "Tom Hill", "text": "It does look yubikey-esque<br/>", "time": "2022-03-25T13:28:16Z"}, {"author": "Murray Kucherawy", "text": "I was going to say \"Yes, we have some tllgbkndhfhfbdbvevgulcggbiebunve\".<br/>", "time": "2022-03-25T13:28:27Z"}, {"author": "Haoyu Song", "text": "@greg that is also a draft proposal and I have made the comparison and give the reason why we have this one<br/>", "time": "2022-03-25T13:28:37Z"}, {"author": "Boris Khasanov", "text": ":))<br/>", "time": "2022-03-25T13:28:38Z"}, {"author": "Greg Mirsky", "text": "@Ahmed, are you suggesting that you do not allow UDP transport if Path Tracing is used?<br/>", "time": "2022-03-25T13:29:31Z"}, {"author": "~~dhruv~~dhody~~", "text": "@mike that document is now cooked! i am sure ketan would not like that<br/>", "time": "2022-03-25T13:29:42Z"}, {"author": "Ketan Talaulikar", "text": "@ Dhruv, <a href=\"https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-22#section-8.6\" rel=\"nofollow\">https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-22#section-8.6</a> covers this<br/>", "time": "2022-03-25T13:30:03Z"}, {"author": "~~dhruv~~dhody~~", "text": "It is in RFC Ed Queue :)<br/>", "time": "2022-03-25T13:30:03Z"}, {"author": "Ketan Talaulikar", "text": "it is covered - though not directly/explicitly<br/>", "time": "2022-03-25T13:30:23Z"}, {"author": "Ketan Talaulikar", "text": "if we put 1 and 1 together to get to 2<br/>", "time": "2022-03-25T13:30:33Z"}, {"author": "Jie Dong", "text": "is the composite candidate path in the draft the same as what is called \"sr policy group\" in this document?<br/>", "time": "2022-03-25T13:31:55Z"}, {"author": "~~dhruv~~dhody~~", "text": "@ ketan - this is not at the SR policy level but at the individual constituent SR policy <br/>", "time": "2022-03-25T13:32:05Z"}, {"author": "Ketan Talaulikar", "text": "@dhruv yes<br/>", "time": "2022-03-25T13:32:16Z"}, {"author": "Ahmed Abdelsalam", "text": "@ Greg, as documented in the draft, we use probe packets. There is no UDP.<br/>", "time": "2022-03-25T13:32:19Z"}, {"author": "Andrew Alston", "text": "Thanks guys :)<br/>", "time": "2022-03-25T13:32:23Z"}, {"author": "~~dhruv~~dhody~~", "text": "thanks<br/>", "time": "2022-03-25T13:32:27Z"}, {"author": "~~dhruv~~dhody~~", "text": "bye! hope to see in person next! <br/>", "time": "2022-03-25T13:32:36Z"}, {"author": "Yuya Kawakami", "text": "Thank you!<br/>", "time": "2022-03-25T13:32:39Z"}, {"author": "Boris Khasanov", "text": "thanks a lot!<br/>", "time": "2022-03-25T13:32:40Z"}, {"author": "Andrew Alston", "text": "Feel free to reach out if anyone needs anything from my side as well !<br/>", "time": "2022-03-25T13:32:43Z"}, {"author": "Justin Iurman", "text": "@Haoyu I understand the reason(s) why you proposed such a draft, but as Greg said, there are already solutions. If you don't want to use EHs, then use SRv6 encapsulation. If it's a matter of available space limit (both EHs and SRv6), then why not using DEX? I just don't think pushing IOAM after layer 4 is a good idea, kinda breaks the semantics<br/>", "time": "2022-03-25T13:32:50Z"}, {"author": "Tom Hill", "text": "See you all in July :)<br/>", "time": "2022-03-25T13:32:52Z"}]