[{"author": "Ron Bonica", "text": "I know that it is a bit late for this comment, but doesn't this draft belong in the INT Area?
", "time": "2022-03-21T13:37:01Z"}, {"author": "Adrian Farrel", "text": "I'd be interested to know how this work could relate to service level YANG models especially related to \"requesting QoS\" in VPN+ and network slicing
", "time": "2022-03-21T13:39:54Z"}, {"author": "Aseem Choudhary", "text": "Hi Adrian, I can check service level YANG models and get back on this.
", "time": "2022-03-21T13:51:27Z"}, {"author": "Jeffrey Haas", "text": "Acee, no need to carry to mic, but it might be worthwhile mentioning to OpenConfig to update the small number of places they have similar terminology in need of update.
", "time": "2022-03-21T13:51:38Z"}, {"author": "Jeffrey Haas", "text": "Lada
", "time": "2022-03-21T13:52:25Z"}, {"author": "Lou Berger", "text": "yes
", "time": "2022-03-21T13:52:35Z"}, {"author": "Jari Arkko", "text": "+1 for making the language changes!
", "time": "2022-03-21T13:53:05Z"}, {"author": "Christian Hopps", "text": "yes
", "time": "2022-03-21T13:54:19Z"}, {"author": "Peter Hessler", "text": "hum
", "time": "2022-03-21T13:54:24Z"}, {"author": "Christian Hopps", "text": "That was impressive number of hands
", "time": "2022-03-21T13:55:21Z"}, {"author": "Jeff Tantsura", "text": "thanks everyone for voting!
", "time": "2022-03-21T13:57:42Z"}, {"author": "Jari Arkko", "text": "Can someone post the link to the issues?
", "time": "2022-03-21T14:01:18Z"}, {"author": "Dhruv Dhody", "text": "https://github.com/APN-Community/Issues/issues
", "time": "2022-03-21T14:02:06Z"}, {"author": "Jeff Tantsura", "text": "thanks!
", "time": "2022-03-21T14:02:16Z"}, {"author": "Shuping Peng", "text": "hi Lars, your issue is the first one, and it was responsed but not closed by you. https://github.com/APN-Community/Issues/issues/1
", "time": "2022-03-21T14:06:38Z"}, {"author": "Shuping Peng", "text": "it is open for you to reply and comment any time
", "time": "2022-03-21T14:07:01Z"}, {"author": "Lars Eggert", "text": "thanks, then i misremembered. so what happens when a hop can't satisfy the reqs? does the flow get rejected (and how), or do we fall back to best-effort, and how would an app then even benefit from apn?
", "time": "2022-03-21T14:09:29Z"}, {"author": "Jari Arkko", "text": "The IAB document: https://datatracker.ietf.org/doc/html/draft-iab-path-signals-collaboration
", "time": "2022-03-21T14:12:22Z"}, {"author": "Shuping Peng", "text": "@Jari, your questions on the two issues have been covered in the issue list, please check and comment https://github.com/APN-Community/Issues/issues
", "time": "2022-03-21T14:15:02Z"}, {"author": "Shuping Peng", "text": "This is a generic framework, and open for solutions
", "time": "2022-03-21T14:15:44Z"}, {"author": "Shuping Peng", "text": "@Lars Eggert, here is the response to your raised issue, if you have any comment please directly comment on it: APN-Github commented on 6 Dec 2021
As described in https://datatracker.ietf.org/doc/html/draft-li-apn-framework-04#section-5, the APN requirements include APN Attribute Conveying Requirements and APN attribute Handling Requirements.
In the APN attributes, the carrying of the APN parameters is optional as stated in https://datatracker.ietf.org/doc/html/draft-li-apn-header-00#section-3. The typical APN parameters are the network performance requirements such as bandwidth, latency, etc.
If a hop cannot meet the APN requirements, which would mean that the hop cannot handle the APN attributes, then it will be up to the local configuration. We can explore more on this topic, but generally the flow needs to be forwarded without any interruption, probably in a default mode.
", "time": "2022-03-21T14:17:53Z"}, {"author": "Lars Eggert", "text": "thanks, i saw that. but saying \"will be up to the local configuration\" is basically saying that apps will not be able to rely on a predictable response from an apn network, i.e., they will need to be coded for a best effort network anyway
", "time": "2022-03-21T14:19:17Z"}, {"author": "Adrian Farrel", "text": "@lars Isn't that exactly the point. I think you are saying \"This document doesn't work on the problem I want to work on,\" and it is OK to say that, but not to say \"...and therefore this approach is not valid.\"
", "time": "2022-03-21T14:20:30Z"}, {"author": "Adrian Farrel", "text": "It's like DiffServ. You set the colour, but you don't get a guaranty from the network
", "time": "2022-03-21T14:21:08Z"}, {"author": "Jeff Tantsura", "text": "@Lars/Shuping - please take this to the RTGWG list, so there's a paper trail and people can react/comment
", "time": "2022-03-21T14:21:51Z"}, {"author": "John Scudder", "text": "\"paper\", heh
", "time": "2022-03-21T14:22:04Z"}, {"author": "Jeff Tantsura", "text": ":) muscle memory
", "time": "2022-03-21T14:22:23Z"}, {"author": "Shuping Peng", "text": "Thank you, Jeff.
", "time": "2022-03-21T14:25:50Z"}, {"author": "Shuping Peng", "text": "The issues and the responses to the issues have all been recorded in the Github and posted in the apn mailing list apn@ietf.org, and separated emails have been directly sent to the issue raisers. People can always review and comment.
", "time": "2022-03-21T14:26:00Z"}, {"author": "Shuping Peng", "text": "https://mailarchive.ietf.org/arch/browse/apn/?gbt=1&index=#
", "time": "2022-03-21T14:26:13Z"}, {"author": "Shuping Peng", "text": "https://github.com/APN-Community/Issues/issues
", "time": "2022-03-21T14:26:22Z"}, {"author": "Yingzhen Qu", "text": "The draft is informational, is it intentional?
", "time": "2022-03-21T14:26:44Z"}, {"author": "Lou Berger", "text": "I think this is interesting work and worth continuing to discuss @IETF
", "time": "2022-03-21T14:27:01Z"}, {"author": "Stewart Bryant", "text": "+1
", "time": "2022-03-21T14:27:22Z"}, {"author": "Lou Berger", "text": "- no idea which WG though
", "time": "2022-03-21T14:27:25Z"}, {"author": "Wesley Eddy", "text": "I think it's great to continue discussing; I don't think there is industry demand for a standard (yet).
", "time": "2022-03-21T14:27:47Z"}, {"author": "Stewart Bryant", "text": "We have a big problem with advanced work that does not naturally fit in IETF as it is not yet reread for deployment but is rejected by IRTF who do not seem to like routing problems
", "time": "2022-03-21T14:28:49Z"}, {"author": "Adrian Farrel", "text": "Certainly seems like there should be a home for discussing the engineering issues that come up with satellite networks. This is rapidly moving beyond research.
", "time": "2022-03-21T14:29:11Z"}, {"author": "Jeff Tantsura", "text": "agree
", "time": "2022-03-21T14:29:27Z"}, {"author": "Stewart Bryant", "text": "However to remain relevant and we need to be working to where the ball will be, not just where it is today - this is a structural IETF problem that IESG and IAB need to work on
", "time": "2022-03-21T14:30:14Z"}, {"author": "Cheng Li", "text": "agree\uff0csatellite network seems very interesting, and we need a place for discussing it for sure
", "time": "2022-03-21T14:30:33Z"}, {"author": "Boris Khasanov", "text": "like specific WG?
", "time": "2022-03-21T14:30:56Z"}, {"author": "Cheng Li", "text": "yes, a WG may be good, IMHO
", "time": "2022-03-21T14:31:19Z"}, {"author": "Lou Berger", "text": "or an existing one, e.g., MANET
", "time": "2022-03-21T14:31:35Z"}, {"author": "Adrian Farrel", "text": "The standard/proprietary question is important, however. I think we have previous examples of the benefits of standards-based approaches even in proprietary networks.
", "time": "2022-03-21T14:31:49Z"}, {"author": "Peter Hessler", "text": "my previous job was working on designing a satellite network constellation, and standardization would have helped us address [redacted] issues
", "time": "2022-03-21T14:32:09Z"}, {"author": "Stewart Bryant", "text": "Not to minimise sat - there are other advanced RTG problems that are too big for RTGWG yet we have no good way to find a good venue for
", "time": "2022-03-21T14:32:15Z"}, {"author": "Lou Berger", "text": "the same point was raised when talking about IGP extension back when multi-vendor IGPs weren't a reality
", "time": "2022-03-21T14:32:41Z"}, {"author": "Tony Li", "text": "Is there anyone from Starlink or Kuiper at IETF????
", "time": "2022-03-21T14:32:45Z"}, {"author": "Jeff Tantsura", "text": "MANET might be a choice for the routing protocol
", "time": "2022-03-21T14:32:50Z"}, {"author": "Jie Dong", "text": "+1 to Adrian's point
", "time": "2022-03-21T14:32:53Z"}, {"author": "Adrian Farrel", "text": "However, some of the proposed re-purposing/overloading of addresses cuts into my slot at the end of this session.
", "time": "2022-03-21T14:32:54Z"}, {"author": "Jeff Tantsura", "text": "@tony - very good question
", "time": "2022-03-21T14:33:42Z"}, {"author": "Stewart Bryant", "text": "One of the difficulties with digital sat is that is is firmly in IATA territory, especially given recent applications
", "time": "2022-03-21T14:34:46Z"}, {"author": "Jeffrey Haas", "text": "The draft under discussion for bfd return path is https://datatracker.ietf.org/doc/html/draft-ietf-mpls-bfd-directed-19
", "time": "2022-03-21T14:39:41Z"}, {"author": "Jeffrey Haas", "text": "Although as best I understand the draft, that's for lsping for mpls, not srv6.
", "time": "2022-03-21T14:40:13Z"}, {"author": "Greg Mirsky", "text": "Good point, Jeff. Thank you. Will work on multi-part ICMP extension in support of directing the reverse direction of a BFD session
", "time": "2022-03-21T14:41:35Z"}, {"author": "Jeffrey Haas", "text": "Thanks, Greg. You've anticipated my suggestion for followup. Even though the work probably needs to be done in spring, the mpls chairs will probably want to be kept in the loop.
", "time": "2022-03-21T14:42:21Z"}, {"author": "Cheng Li", "text": "for SRv6\uff0cyou can see this draft, it mainly describes the mechanism of using BSID for BFD.https://datatracker.ietf.org/doc/draft-chen-spring-sr-policy-for-ubfd/
", "time": "2022-03-21T14:43:00Z"}, {"author": "Jeff Tantsura", "text": "@greg, specific question for now of at the end?
", "time": "2022-03-21T14:44:19Z"}, {"author": "Jeffrey Haas", "text": "Thank you, Cheng Li. This draft wasn't in the BFD WG's list of monitored drafts. I'd invite you to post to the rtg-bfd@ietf.org list to draw additional attention to your work.
", "time": "2022-03-21T14:45:01Z"}, {"author": "Cheng Li", "text": "thank you @jeff
", "time": "2022-03-21T14:45:23Z"}, {"author": "Cheng Li", "text": "@Jeffrey, LOL
", "time": "2022-03-21T14:45:43Z"}, {"author": "Boris Khasanov", "text": "@Cheng Li - interesting and important indeed!
", "time": "2022-03-21T14:46:01Z"}, {"author": "Jeffrey Haas", "text": "https://trac.ietf.org/trac/bfd/wiki/Non-BFD%20Working%20Group%20BFD-related%20Activities
", "time": "2022-03-21T14:48:06Z"}, {"author": "Cheng Li", "text": "thank you @boris
", "time": "2022-03-21T14:52:21Z"}, {"author": "Cheng Li", "text": ":)
", "time": "2022-03-21T14:52:27Z"}, {"author": "Yisong Liu", "text": "@jeff, we have submit the sbfd path consistency draft in BFD WG, Pls see https://datatracker.ietf.org/doc/draft-lin-sbfd-path-consistency-over-srv6/
", "time": "2022-03-21T14:54:45Z"}, {"author": "Christian Hopps", "text": "hnm just lost them
", "time": "2022-03-21T14:56:17Z"}, {"author": "Jeffrey Haas", "text": "Yisong, thanks for that. Your draft had fallen into the wrong bit of my mailbox. I'll comment on it later.
", "time": "2022-03-21T14:56:32Z"}, {"author": "Christian Hopps", "text": "or am i the one that's lost..
", "time": "2022-03-21T14:56:36Z"}, {"author": "John Scudder", "text": "what are you talking about, chris?
", "time": "2022-03-21T14:56:49Z"}, {"author": "Christian Hopps", "text": "lost all audio and video from the room
", "time": "2022-03-21T14:57:05Z"}, {"author": "John Scudder", "text": "if you mean the a/v feed, it LGTM
", "time": "2022-03-21T14:57:06Z"}, {"author": "Christian Hopps", "text": "it's me thne
", "time": "2022-03-21T14:57:13Z"}, {"author": "Yisong Liu", "text": "@jeff, Thanks, very appreciate for your review and comments
", "time": "2022-03-21T14:58:44Z"}, {"author": "Jeff Tantsura", "text": "@greg - you are still in queue, do you have a question?
", "time": "2022-03-21T15:02:33Z"}, {"author": "Jim Uttaro", "text": "Is the pool bounded?
", "time": "2022-03-21T15:03:07Z"}, {"author": "Jeffrey Haas", "text": "Chairs should mute Greg.
", "time": "2022-03-21T15:06:57Z"}, {"author": "Jeff Tantsura", "text": "thanks jeff, done
", "time": "2022-03-21T15:07:49Z"}, {"author": "Jeff Tantsura", "text": "@robin - please send your question/comment to the list
", "time": "2022-03-21T15:20:34Z"}, {"author": "Stewart Bryant", "text": "Re IRTF - not handles well at all
", "time": "2022-03-21T15:32:29Z"}, {"author": "Stewart Bryant", "text": "IRTF needs to be more open to work in this area and more proactive
", "time": "2022-03-21T15:33:14Z"}, {"author": "Stewart Bryant", "text": "Thi sis not really ICN which has its own bagagge
", "time": "2022-03-21T15:33:47Z"}, {"author": "Gyan Mishra", "text": "Adrian, I think this work is very useful and I think IETF may have a home here RTGWG and maybe even TEAS
", "time": "2022-03-21T15:33:51Z"}, {"author": "Haomian Zheng", "text": "This work is useful, but may need to be broke into a few pieces to evaluate the impact on various protocols...
", "time": "2022-03-21T15:34:28Z"}, {"author": "Dhruv Dhody", "text": "Thanks! Great presentations!
", "time": "2022-03-21T15:34:50Z"}, {"author": "Stewart Bryant", "text": "The problem with breaking it up is loss of critical mass and cross polination
", "time": "2022-03-21T15:34:57Z"}, {"author": "Zhenbin Li", "text": "+1
", "time": "2022-03-21T15:34:58Z"}, {"author": "Zhenbin Li", "text": "@dhruv
", "time": "2022-03-21T15:35:15Z"}]