I would like to move over from LSR to PALS for the RDI presentation. Could someone post just when the presentation prior to RDI starts?
", "time": "2022-11-09T09:35:17Z"}, {"author": "Tarek Saad", "text": "@Jeff Agenda is at https://notes.ietf.org/notes-ietf-115-pals?both
", "time": "2022-11-09T09:49:07Z"}, {"author": "Tarek Saad", "text": "@Jeff, RDI is #6 which is ~60mins from starting point
", "time": "2022-11-09T09:49:54Z"}, {"author": "Jeffrey Haas", "text": "Why, yes Tarek... that's known. In the absence of someone saying yes I've had to join the video stream so I can see the presentation that I have to mostly ignore because I'm in the other session that I mentioned.
", "time": "2022-11-09T09:49:59Z"}, {"author": "Tony Li", "text": "We need to support arbitrary stuff ahead of MNA in the PSD.
", "time": "2022-11-09T10:19:55Z"}, {"author": "Tarek Saad", "text": "@Tony, the offset seems to help indicate the start of PSD in case it is not immediately after BoS
", "time": "2022-11-09T10:25:05Z"}, {"author": "Tony Li", "text": "That is exactly the point.
", "time": "2022-11-09T10:25:57Z"}, {"author": "Tony Li", "text": "@Stewart Bryant If we want something simpler, than we should reduce the requirements. See our previous discussion about design priorities. We have chosen maximum generality. With that comes maximum complexity.
", "time": "2022-11-09T10:27:39Z"}, {"author": "Andrew Alston", "text": "I have to say - for me reading this and looking at it (the MNA stuff)- yes - there is an issue potentially with PSD - but I worry that this just... seems to be complex enough that it may end up being very fragile - and I worry that this could end up with enough deployment teething problems that it drives people away from it - and once that happens its hard to get operators to come back again - it just seems - fragile through complexity - but thats very difficult to put a direct finger on if that makes sense
", "time": "2022-11-09T10:35:49Z"}, {"author": "Andrew Alston", "text": "(and I realize thats a very subjective non-technical comment - but I do feel that - speaking with only my operator hat on - I have an uneasy feeling - that the complexity could end up hurting - badly)
", "time": "2022-11-09T10:38:02Z"}, {"author": "Tony Li", "text": "Please feel free to propose changes, propose text, or propose requirements that could be removed. If you want a huge decrease in complexity, then let's remove the requirement for arbitrary action ordering. :-)
", "time": "2022-11-09T10:39:46Z"}, {"author": "Stewart Bryant", "text": "RDI running
", "time": "2022-11-09T10:40:47Z"}, {"author": "Joel Halpern", "text": "@Tony Li Not sure which version of \"arbitrary action ordering\" you mean. What I hope I was clear about at the microphone is that the \"ordered\" bit as defined seems to invite complexity for no added value.
", "time": "2022-11-09T10:40:57Z"}, {"author": "Tony Li", "text": "@Joel Halpern In the course of discussions, we accepted the design requirement that we support any ordering of actions. Things simplify considerably if we restrict our options for ordering. For example, if we just remove the O bit and say that PSD is in encoding order after all ISD. As it stands right now, the O bit kicks you out of the fast path.
", "time": "2022-11-09T10:43:07Z"}, {"author": "Andrew Alston", "text": "Yeah I am still not sure I understand the need for the O bit and why non-ordered actions would actually be needed
", "time": "2022-11-09T10:44:34Z"}, {"author": "Stewart Bryant", "text": "how do we deal with the ISD - PSD ordering
", "time": "2022-11-09T10:44:38Z"}, {"author": "Tony Li", "text": "If you relax ordering, then you let the implementation use its optimal ordering of evaluation.
", "time": "2022-11-09T10:45:35Z"}, {"author": "Tony Li", "text": "@Stewart Bryant One way would be to say that PSD is always after ISD.
", "time": "2022-11-09T10:45:53Z"}, {"author": "Joel Halpern", "text": "@Tony, sure, but if you have to code to be able to do things in order, then you probably lose more cycles than any \"optimal ordering\" adds back.
", "time": "2022-11-09T10:46:20Z"}, {"author": "Tony Li", "text": "The O bit kicks you out of the fast path, so a performance hit is a given.
", "time": "2022-11-09T10:47:25Z"}, {"author": "Joel Halpern", "text": "1) The O bit does not help with the ordering of PSD vs ISD. 2) There is already another mechanism in the draft to try to deal with needing to interleave ISD and PSD. 3) Net: Just define PSD as always after ISD and life gets simpler.
", "time": "2022-11-09T10:47:59Z"}, {"author": "Joel Halpern", "text": "As I said initially at the microphone, presumably as a result of being a compromise among encoding proposals, the draft seems to have multiple ways of doing anything. That may be good for python. it is not good for interoperable protocol specifications.
", "time": "2022-11-09T10:50:35Z"}, {"author": "Jeffrey Haas", "text": "@Hongyi Huang if you have further questions about my microphone comments please either email me or the bfd mail list
", "time": "2022-11-09T10:50:48Z"}, {"author": "Stewart Bryant", "text": "@loa - do you want to introduce the open mic session?
", "time": "2022-11-09T10:51:50Z"}, {"author": "Hongyi Huang", "text": "@Jeffrey Haas Thanks for your important comments and suggestions. I think I would touch you later or discuss it in bfd further.
", "time": "2022-11-09T11:04:51Z"}]