Subject: FYI/Feedback draft-bryant-arch-fwd-layer-ps-00

From: Toerless Eckert <[email-masked]>
Date: Tue, 24 Mar 2020 03:13:26 +0100

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-masked] 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)

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Tue, 24 Mar 2020 03:25:54 +0000

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-masked]] On Behalf Of Toerless Eckert
Sent: Tuesday, March 24, 2020 10:13 AM
To: [email-masked]
Cc: [email-masked]
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-masked] 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:

Cheers

_______________________________________________
rtgwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtgwg