Hi! Thanks a lot for the good summary of some very interesting observations.
Here are some comments at first glance for section 6.1.1 ---- I think there are some other restrictions of RFC8200 notable to me that may cause "Forwarding Layer Problem". (1) restrictions allowing only 1 routing header or similar thing. Forwarding plane has to count how many routing headers. As Radia Perlman said in her famous book: ISO, being a standards body, was reluctant to specify how to define options -- thus, it provided this level of "flexibility". However, just to show that it does have the clout to make rules, it decreed that no option should appear twice. This restriction places a burden on routers (are they supposed to check that no option appears twice every time they forward a packet?) and reduces flexibility. (2) the recommended order of the various extension headers: When more than one extension header is used in the same packet, it is recommended that those headers appear in the following order: IPv6 nodes must accept and attempt to process extension headers in any order and occurring any number of times in the same packet. The later one is good for "forwarding layer" process, and the former one is not good, and is not the practice and consideration in years of RFCs, e.g., RFC6275 and RFC7837. (3) The classification of different EH place holder, with some restriction. IPv4 does support Options but doesn't have such classification of EH or restrictions. The IPv6 spec does this classification based on some past patterns, but has some text only fit to some EH, or based on the recommended order, causing "forwarding layer problem" or "reduces flexibility". For example, Can someone invent a new routing header other than the one the place holder (with 4 fields, especially SL field) by the current RFC8200 ? Can someone use DO header working like routing header ? Thanks Jingrong -----Original Message----- From: rtgwg [mailto:[email protected]] On Behalf Of Toerless Eckert Sent: Tuesday, March 24, 2020 10:13 AM To: [email protected] Cc: [email protected] Subject: FYI/Feedback draft-bryant-arch-fwd-layer-ps-00 Dear intarea WG We think draft https://datatracker.ietf.org/doc/draft-bryant-arch-fwd-layer-ps/ does in part touch aspects related to routing area, so we are interested in your opinion/feedback. We think its mostly architectual through, so maybe [email protected] is more appropriate for overall discussions on the topic right now. Before Corona, we had planned to have an inoffical side-meeting to discuss the topic, we have now set up a virtual inofficial side-meeting instead, This wednesday 03/25/2020, 1500 UTC. Info here: https://trac.ietf.org/trac/ietf/meeting/wiki/ietf107replacements https://etherpad.wikimedia.org/p/v107-side-meeting Cheers Toerless (for the authors) _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
