Confirmed
", "time": "2022-11-08T09:30:08Z"}, {"author": "Xueyan Song", "text": "can hear
", "time": "2022-11-08T09:30:26Z"}, {"author": "Gaurav Dawra", "text": "Can Hear
", "time": "2022-11-08T09:37:12Z"}, {"author": "Andrew Alston", "text": "A reminder AGAIN about masks please - if you arent eating or drinking masks are mandatory
", "time": "2022-11-08T09:37:27Z"}, {"author": "Kiran", "text": "I cant here
", "time": "2022-11-08T09:38:15Z"}, {"author": "Joel Halpern", "text": "Kiran, are you still having trouble hearing Rakesh?
", "time": "2022-11-08T09:40:32Z"}, {"author": "Ted Hardie", "text": "I can't get into the hedgeDoc notes--is it working for others? Are the notes being taken there?
", "time": "2022-11-08T09:40:42Z"}, {"author": "Kiran", "text": "yes
", "time": "2022-11-08T09:40:53Z"}, {"author": "Joel Halpern", "text": "Is it audible to other remote people?
", "time": "2022-11-08T09:41:14Z"}, {"author": "Eduard V", "text": "yes
", "time": "2022-11-08T09:41:22Z"}, {"author": "Boris Khasanov", "text": "yes, it is audible
", "time": "2022-11-08T09:41:36Z"}, {"author": "Joel Halpern", "text": "Kiran, have you tried clicking the restart button in meetecho?
", "time": "2022-11-08T09:41:39Z"}, {"author": "Joel Halpern", "text": "@Ted Hardie - I can open the hedgedoc from the agenda page, and it appears to have minutes started.
", "time": "2022-11-08T09:43:05Z"}, {"author": "Ted Hardie", "text": "@Joel. Thanks; something on my end then.
", "time": "2022-11-08T09:43:36Z"}, {"author": "Kiran", "text": "It is audible now thanks
", "time": "2022-11-08T09:44:30Z"}, {"author": "Anthony Somerset", "text": "wondering if there is a more generic network issue on site
", "time": "2022-11-08T09:48:20Z"}, {"author": "Jeffrey Haas", "text": "For upcoming mic comment for BFD presentation:
\nhttps://wiki.ietf.org/en/group/bfd/non-wg-related-activities
https://datatracker.ietf.org/doc/html/rfc8986#section-4.2
", "time": "2022-11-08T10:00:43Z"}, {"author": "Ketan Talaulikar", "text": "@Jie please look for L2 bundle member in the above section
", "time": "2022-11-08T10:01:13Z"}, {"author": "Ketan Talaulikar", "text": "End.X can be also used for the scenario presented in this draft.
", "time": "2022-11-08T10:02:23Z"}, {"author": "Jie Dong", "text": "@Ketan Talaulikar Thanks for the pointer Ketan. Since End.X is for L3 adjacency, IMO it does not cover the cases where there is no L3 adjacency between two nodes. I agree the L2 bundle case is somehow different from the IP+optical or IP+MTN case, we can discuss further whether it is helpful to make it one use case of End.XU or not.
", "time": "2022-11-08T10:07:19Z"}, {"author": "Joel Halpern", "text": "@Jie Dong if there is a packet adjacency (optical, ethernet, ...) between the two nodes, why is there not an IP adjacency between them? Even if there is no routing adjacency?
", "time": "2022-11-08T10:08:41Z"}, {"author": "Ketan Talaulikar", "text": "@Jie, RFC8986 already covers the use of End.X behavior for L2 Bundle members.
", "time": "2022-11-08T10:08:48Z"}, {"author": "Ketan Talaulikar", "text": "@Joel +1 ... End.X is not limited to IGP adjacencies
", "time": "2022-11-08T10:09:53Z"}, {"author": "Jie Dong", "text": "@Joel Halpern Yes in the cases mentioned in the slides, there is no routing adjacency. Regarding IP adjacency, do you mean the two endpoints need to be in the same network subnet?
", "time": "2022-11-08T10:12:06Z"}, {"author": "Joel Halpern", "text": "@Jie Dong there is no need for a subnet. it can happily be an unnumbered point-to-point IP adjacency. How the controller knows about it is a different quesiton.
", "time": "2022-11-08T10:13:09Z"}, {"author": "Ketan Talaulikar", "text": "@Jie for ptp links subnet match is not required
", "time": "2022-11-08T10:13:22Z"}, {"author": "Shraddha Hegde", "text": "Why are two different modes defined for BFD? It seems with transport mode, all usecases for detecting liveness of the segment list can be satisfied
", "time": "2022-11-08T10:13:51Z"}, {"author": "Ketan Talaulikar", "text": "@Shraddha +1
", "time": "2022-11-08T10:14:09Z"}, {"author": "Andrew Alston", "text": "@Shraddha Hegde +1
", "time": "2022-11-08T10:14:31Z"}, {"author": "Jie Dong", "text": "@Ketan Talaulikar In some cases you don't want to expose that link as a layer-3 adjacency to IGP. It is only used for cross-layer TE path optimization. and for P2P IP link you would need to create L3 logical interfaces for each underlay ptp link, which may not be necessary or not wanted by the operator
", "time": "2022-11-08T10:21:40Z"}, {"author": "Jeffrey Haas", "text": "@Shraddha Hegde I don't pretend to speak for the authors of that bfd document, but there have been cases over BFD's lifetime that there's a desire to probe a higher layer endpoint, and a lower layer portion of the same endpoint. In most cases they often share fate, so probing one of the forms is sufficient to satisfy reachability for the other. (See example of bfd for ipv4 being sufficient in some cases for ipv6 on same link.) However, some hardware platforms may be architected that just because transport is working and you can test to that endpoint, the underlying service directly behind that endpoint may be separably tested.
", "time": "2022-11-08T10:24:56Z"}, {"author": "Ketan Talaulikar", "text": "@Jie I didn't talk about enabling IGP on that optical link. L3 adjacency is different from IGP adjacency. End.X can be used for L3 adjacency as well as L2 bundle member links within a L3 LAG bundle
", "time": "2022-11-08T10:25:54Z"}, {"author": "Ketan Talaulikar", "text": "per RFC8986
", "time": "2022-11-08T10:25:59Z"}, {"author": "Shraddha Hegde", "text": "@Jeffrey Haas In SRv6 if the service end need to be tested the service SID can be added to stack in transport mode itself. Tunnel mode seems redundant
", "time": "2022-11-08T10:34:17Z"}, {"author": "Mengxiao Chen", "text": "@Shraddha Tunnel mode is more friendly for hardware in some cases. One example is that, the inner packet in tunnel mode only contains ipv6 header and udp header which is easier for low-performance device to process. Another example: the checksum in UDP header includes the IPv6 header, in transport mode, the DA in outer IPv6 header changes in SRv6 forwarding, but in tunnel mode, the DA of inner IPv6 header does not change.
", "time": "2022-11-08T10:35:44Z"}, {"author": "Ketan Talaulikar", "text": "To add to what Shraddha mentioned, the tunnel part here is provided by the SRv6 service and not the BFD implementation.
", "time": "2022-11-08T10:35:51Z"}, {"author": "Jeffrey Haas", "text": "I won't argue what feels redundant or not. These conversations for BFD layer termination always end up having strong opinions from each participant depending on what layer they care about, and what their hardware or software finds easier. :-)
", "time": "2022-11-08T10:40:10Z"}, {"author": "Jeffrey Haas", "text": "See most recently the discussion for BFD for Ethernet LAGs.
", "time": "2022-11-08T10:40:56Z"}, {"author": "Ketan Talaulikar", "text": "@Jeff, I meant to say that the use of transport or tunnel mode is determined by the service using BFD
", "time": "2022-11-08T10:41:25Z"}, {"author": "Jeffrey Haas", "text": "@Ketan Talaulikar Understood. Some want to test to service, some want to test to endpoint. Both perspectives have favor among different parties.
", "time": "2022-11-08T10:42:34Z"}, {"author": "Jim Uttaro", "text": "Would this be considered an Option B like mapping ?
", "time": "2022-11-08T10:42:55Z"}, {"author": "Ketan Talaulikar", "text": "@Jim this is at the transport layer. Perhaps I misunderstand your Q?
", "time": "2022-11-08T10:44:06Z"}, {"author": "Dan Voyer", "text": "@Jim, yes
", "time": "2022-11-08T10:44:21Z"}, {"author": "Dhruv Dhody", "text": "+1 ketan, why this needs to be standardized, what protocol changes are needed and more importantly why?
", "time": "2022-11-08T11:06:24Z"}, {"author": "Jie Dong", "text": "On the previous presentation, there is a WG document on resource-aware segments, which is to associate network resource attributes with SR SIDs, it seems a reference to that document is needed.
", "time": "2022-11-08T11:24:07Z"}, {"author": "Weiqiang Cheng", "text": "Thanks Jie, we will look into the draft.
", "time": "2022-11-08T11:27:05Z"}, {"author": "Eduard V", "text": "the name of the last draft is misleading. It is not \"Native IPv6\", it is \"Srv6\"
", "time": "2022-11-08T11:27:09Z"}, {"author": "Ketan Talaulikar", "text": "Have the authors of this draft looked at https://datatracker.ietf.org/doc/draft-ietf-spring-sr-replication-segment/ and why that does not also cover their use-case?
", "time": "2022-11-08T11:31:14Z"}, {"author": "Ketan Talaulikar", "text": "Also https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-evpn-sr-p2mp/ to get the full picture.
", "time": "2022-11-08T11:34:19Z"}]