good morning :-)
", "time": "2024-03-19T23:30:26Z"}, {"author": "Shuping Peng", "text": "Good morning!
", "time": "2024-03-19T23:31:14Z"}, {"author": "Dhruv Dhody", "text": "5 am for you ketan! That is real morning...
", "time": "2024-03-19T23:31:23Z"}, {"author": "Martin Horneffer", "text": "good morning! or whatever you say after 2 hours of sleep ;-)
", "time": "2024-03-19T23:32:02Z"}, {"author": "Antoine Fressancourt", "text": "Good night from EU
", "time": "2024-03-19T23:32:19Z"}, {"author": "Tony Przygienda", "text": "so something checking a checksum is supposed to be a broken device? this kind of \"logic\" utterly defies me ...
", "time": "2024-03-19T23:44:35Z"}, {"author": "Ketan Talaulikar", "text": "@Tony that \"something\" is a middle box ... where is it specified that it needs to do L4 checksum verification?
", "time": "2024-03-19T23:45:39Z"}, {"author": "Antoine Fressancourt", "text": "+1 Ketan
", "time": "2024-03-19T23:46:04Z"}, {"author": "Tony Przygienda", "text": "so we build networks now where we carry packets that have broken checksums and consider that secure/reliable/coherent? as I say the \"logic\" applied here utterly defies me
", "time": "2024-03-19T23:46:43Z"}, {"author": "Ketan Talaulikar", "text": "Also, middleboxes have to and do adopt to new technologies. They don't get to block new technologies ... think any new encapsulation being introduced.
", "time": "2024-03-19T23:47:05Z"}, {"author": "Darren Dukes", "text": "Checksums are not broken - the destination is able to verify it just fine.
", "time": "2024-03-19T23:47:30Z"}, {"author": "Tony Przygienda", "text": "a new encapsulation is not a broken checksum. next we will allow to present stuff where stuff protected by security fingerprints is modified I guess. 'nuff for me ...
", "time": "2024-03-19T23:48:24Z"}, {"author": "Ketan Talaulikar", "text": "@TonyP ... where are you seeing a broken checksum ;-)
", "time": "2024-03-19T23:50:51Z"}, {"author": "Antoine Fressancourt", "text": "If a middlebox breaks end to end security, we assume the middle box raises a security issue. Why wouldn't it be the same for checksums that are supposed to be checked at the destination?
", "time": "2024-03-19T23:54:57Z"}, {"author": "Andrew Alston", "text": "If you are doing show of hands polls please run that through meetecho so those of us online can participate as well :)
", "time": "2024-03-19T23:56:05Z"}, {"author": "Christian Hopps", "text": "polls of the room should probably use meetecho..
", "time": "2024-03-19T23:56:10Z"}, {"author": "Ketan Talaulikar", "text": "Next we will have someone asking for middlebox to verify the IPsec or TLS in the middle of the network :-)
", "time": "2024-03-19T23:56:28Z"}, {"author": "Cheng Li", "text": "@Antoine, fully agree!
", "time": "2024-03-19T23:57:11Z"}, {"author": "Alvaro Retana", "text": "Yes, I just wanted to get an idea if people had read the document. Sorry.
", "time": "2024-03-19T23:57:33Z"}, {"author": "Tony Przygienda", "text": "well, good luck tryhing to figure out what's going on in your network somewhere in the middle if you have packets thaty look like v6 but may/may not be v6 and have broken checksums.
", "time": "2024-03-19T23:58:30Z"}, {"author": "Tony Przygienda", "text": "anyway, I don't think this needs further messaging
", "time": "2024-03-19T23:59:07Z"}, {"author": "Ketan Talaulikar", "text": "@ TonyP, that last one ... we can agree on!
", "time": "2024-03-19T23:59:27Z"}, {"author": "Tony Przygienda", "text": "so that looks mildly useful to me except that mostly you want to grab something you cannot ask the sender nicely to inject something into the sid list (flowspec basically) ... ;-)
", "time": "2024-03-20T00:10:03Z"}, {"author": "Greg Mirsky", "text": "To follow-up on my comment at the mic https://datatracker.ietf.org/doc/rfc9322/
", "time": "2024-03-20T00:10:28Z"}, {"author": "Greg Mirsky", "text": "the is the In Situ Operations, Administration, and Maintenance (IOAM) Loopback and Active Flags RFC I've mentioned.
", "time": "2024-03-20T00:11:08Z"}, {"author": "Ketan Talaulikar", "text": "+1 to the point Alvaro made
", "time": "2024-03-20T00:13:35Z"}, {"author": "Shuping Peng", "text": "@Greg, the RFC no. has been added in the minutes.
", "time": "2024-03-20T00:15:27Z"}, {"author": "Jim Guichard", "text": "doesnt the previous idea require that the hdr ext length be updated? that's a problem given it is not mutable
", "time": "2024-03-20T00:15:35Z"}, {"author": "Greg Mirsky", "text": "@Jim, IFAICS, IOAM Loopback uses the fixed size IOAM Header without adding information to the original trigger packet
", "time": "2024-03-20T00:17:37Z"}, {"author": "Shraddha Hegde", "text": "The active CP can be updated by controller to satisfy all the resource requirement. why isn't that an option and a new candidate path selection needed?
", "time": "2024-03-20T00:21:36Z"}, {"author": "Martin Horneffer", "text": "agreed. the current path selection procedure is complex enough. IMHO a single preference is enough.
", "time": "2024-03-20T00:23:18Z"}, {"author": "Ketan Talaulikar", "text": "@Shraddha, I think here the need is for the headed to do the monitoring. e.g., delay measurement.
", "time": "2024-03-20T00:23:26Z"}, {"author": "Ketan Talaulikar", "text": "@Martin, this is perhaps better done by marking a CP which is say seeing delay over a threshold as invalid. That way, we don't change the tiebreaker.
", "time": "2024-03-20T00:24:16Z"}, {"author": "Antoine Fressancourt", "text": "Is itthe case that the SR policy is announced once, and the thresholds are updated several times after the initial SR policy announcement ?
", "time": "2024-03-20T00:24:43Z"}, {"author": "Ketan Talaulikar", "text": "@ Antoine, probably not
", "time": "2024-03-20T00:25:15Z"}, {"author": "Zafar Ali", "text": "@ Antonio, the threshold does not change as they are configured but then monitored for CPs.
", "time": "2024-03-20T00:27:11Z"}, {"author": "Antoine Fressancourt", "text": "OK, thanks for your clarification
", "time": "2024-03-20T00:27:35Z"}, {"author": "Himanshu Shah", "text": "it is an additional CP selection criteria based on SLA threshold
", "time": "2024-03-20T00:27:55Z"}, {"author": "Himanshu Shah", "text": "My point is that this is implicit in SR-Policy creation that TE is monitored
", "time": "2024-03-20T00:28:18Z"}, {"author": "Antoine Fressancourt", "text": "@Himanshu This is what I supposed a PCE / controller would do, maybe announcing threshold is required for explaining the path selection for requesting routers
", "time": "2024-03-20T00:30:03Z"}, {"author": "Ketan Talaulikar", "text": "@Himanshu, it becomes super complication if we try to change the selection process by all these parameters - it can be simplified by marking a CP crossing a threshold as \"invalid\" and then fallback to existing CP selection in RFC9256. Thoughts?
", "time": "2024-03-20T00:32:44Z"}, {"author": "Himanshu Shah", "text": "@ketan - exactly. The built-in assumption on SR-Policy that all the CPs are calculated based on the intent that is monitored periodically so when not met.. you select the next priority CP
", "time": "2024-03-20T00:35:04Z"}, {"author": "Ketan Talaulikar", "text": "@Himanshu, true but there is subtlety here. Does the implementation keep monitoring all CPs all the time or only does so for specific CPs when needed.
", "time": "2024-03-20T00:37:08Z"}, {"author": "Srihari Sangli", "text": "Another point is that, each ingress is better suited to check the CP from its point of view as opposed to do all verification from a centralized entity.
", "time": "2024-03-20T00:38:21Z"}, {"author": "Ketan Talaulikar", "text": "@Srihari +1
", "time": "2024-03-20T00:38:37Z"}, {"author": "Yisong Liu", "text": "@Antoine the threshold only need to be announced once, for the specific SR Policy
", "time": "2024-03-20T00:40:12Z"}, {"author": "Diego Achaval", "text": "@Srihari
", "time": "2024-03-20T00:40:17Z"}, {"author": "Diego Achaval", "text": "+1
", "time": "2024-03-20T00:40:26Z"}, {"author": "Yisong Liu", "text": "@Ketan @Srihari thank you for help to reply
", "time": "2024-03-20T00:41:12Z"}, {"author": "Ketan Talaulikar", "text": "@Andrew +1
", "time": "2024-03-20T00:43:02Z"}, {"author": "Dhruv Dhody", "text": "Good points Andrew!
", "time": "2024-03-20T00:43:36Z"}, {"author": "Ketan Talaulikar", "text": "There is no timer for TI-LFA local repair for link down ...
", "time": "2024-03-20T00:43:46Z"}, {"author": "Ketan Talaulikar", "text": "Unless we are dampening the link down itself. Is that the case?
", "time": "2024-03-20T00:44:31Z"}, {"author": "Zafar Ali", "text": "@Andrew I agree with you. I agree with the complexity of the proposal.
", "time": "2024-03-20T00:45:25Z"}, {"author": "Andrew Stone", "text": "BSID complexity vs operational coordination complexity
\n\\_(\u30c4)_/\u00af
", "time": "2024-03-20T00:45:59Z"}, {"author": "Srihari Sangli", "text": "this looks similar to multi-topology routing!
", "time": "2024-03-20T00:46:03Z"}, {"author": "Andrew Stone", "text": "don't get me wrong -> bsids definitely bring their own form complexity. Whether this is less complex or more is unclear to me at the moment
", "time": "2024-03-20T00:46:54Z"}, {"author": "Himanshu Shah", "text": "@ketan - link dampening and rely mainly on single hop IP BFD for consistent behavior
", "time": "2024-03-20T00:46:57Z"}, {"author": "Himanshu Shah", "text": "@andrew - Agree BSIDs are not easy to configure
", "time": "2024-03-20T00:47:26Z"}, {"author": "Andrew Stone", "text": "That's why they should be automatic ;)
", "time": "2024-03-20T00:47:36Z"}, {"author": "Himanshu Shah", "text": "@zafar - We have deployed this solution. It is not that difficult. Contrary I think it is very simple proposal
", "time": "2024-03-20T00:48:35Z"}, {"author": "Himanshu Shah", "text": "Transport Service Provider are very particular about where their traffic transiting through. These are typical TP replacement candidates
", "time": "2024-03-20T00:49:37Z"}, {"author": "Himanshu Shah", "text": "If primary path fails, they want the traffic to be on preprovisioned backup and not wander around the network that they do not have much control over
", "time": "2024-03-20T00:50:31Z"}, {"author": "Himanshu Shah", "text": "@zafar - let us have offline discuss to address your concern..
", "time": "2024-03-20T00:51:58Z"}, {"author": "Zafar Ali", "text": "@Himanshu Sure, happy to discuss them. Thanks!
", "time": "2024-03-20T00:52:25Z"}, {"author": "Bruno Decraene", "text": "@Meetecho \"speakers camera\" is not on the speaker but on the chaits. Not sure whether this is intended.
", "time": "2024-03-20T01:02:43Z"}, {"author": "Dhruv Dhody", "text": "https://www.rfc-editor.org/rfc/rfc9197.html#section-4.5
", "time": "2024-03-20T01:03:25Z"}, {"author": "Amal Karboubi", "text": "@zafar @Andrew thanks for your comments, the coordination between PCE and headend was not complex implementation wise, happy to discuss further offline.
", "time": "2024-03-20T01:04:47Z"}, {"author": "Zafar Ali", "text": "@Amal Sure, happy to discuss more offline. Thanks!
", "time": "2024-03-20T01:05:22Z"}, {"author": "Dhruv Dhody", "text": "Network Attestation For Secure Routing (NASR) for those interested
", "time": "2024-03-20T01:06:25Z"}, {"author": "Andrew Stone", "text": "Amal - yep seems like interaction between pce/headend is clear. My point about complexity is more so the various numerous dependencies in the design and reliance on humans following explicit procedures.
\nbut yeah for sure can chat more!
", "time": "2024-03-20T01:09:11Z"}, {"author": "Srihari Sangli", "text": "what is the proposed frequency for this path verification ? It seems it may be bring more overhead
", "time": "2024-03-20T01:11:02Z"}, {"author": "Antoine Fressancourt", "text": "The intention was to make this path verification on every packet
", "time": "2024-03-20T01:11:56Z"}, {"author": "Srihari Sangli", "text": "is the benefit worth the CPU/wire traffic ?
", "time": "2024-03-20T01:12:40Z"}, {"author": "Antoine Fressancourt", "text": "the overhead in leader space and processing time is a little bit higher than SRH HMAC, but comparable
", "time": "2024-03-20T01:12:42Z"}, {"author": "Antoine Fressancourt", "text": "we are talking 5% more than HMAC TLV computattion
", "time": "2024-03-20T01:13:17Z"}, {"author": "Antoine Fressancourt", "text": "so rather lightweight
", "time": "2024-03-20T01:13:28Z"}, {"author": "Srihari Sangli", "text": "@Antoine, thanks!
", "time": "2024-03-20T01:15:52Z"}]