Extend introduction and remove/edit notes

[elear]

The following text needs to be reworked as you are not publishing some of these:

*Note:* This is the very first version of the SCION Data Plane document. We are aware that the draft is far from perfect, and hope to improve the content in later versions of the document. To reach this goal, any feedback is welcome and much appreciated. Thanks!

*Note:* It is assumed that readers of this draft are familiar with the basic concepts of the SCION next-generation inter-domain network architecture. If not, please find more detailed information in the IETF Internet Drafts [I-D.scion-overview], [I-D.scion-components], [I-D.scion-cppki], and [I-D.scion-cp], as well as in [CHUAT22], especially Chapter 2. A short description of the SCION basic terms and elements can be found in Section 1.1 below.

Also,

From: Ron Bonica The problem statement is weak. Before describing forwarding plane details, you need to tell the readers why they should deploy SCION. You say that the design advantages are:

• It provides control and transparency over forwarding paths the endpoints.        
• It simplifies the packet-processing at routers: Instead of having to perform longest-prefix matching on IP addresses, which requires expensive hardware and substantial amounts of energy, a router can simply access the next hop from the packet header, after having verified the authenticity of the hop field's MAC.

      Is there any benefit in switching, as opposed to routing, at the AS boundary? Yes, routing is expensive. But the router is already there. There is no incremental cost. By contrast, you would have to add a SCION device. Is the real motivation to support new settlement models?

Same issue in other drafts:

• CPPKI https://github.com/scionassociation/scion-cppki_I-D/issues/29
• CP https://github.com/scionassociation/scion-cp_I-D/issues/14

[nicorusti]

Regarding problem statement, we can reuse some text from the overview draft section 1.2, stressing aspects that mostly pertain tom the data plane:

• Address needs of organizations or ecosystems exchanging sensitive information, such as financial institutions, healthcare providers, universities, multinationals, governments, critical and transportation infrastructure operators, which can not always be addressed by leveraging public Internet
• Providing availability inter-domain (e.g. quick reaction to link failure)
• Avoiding reflection attacks
• Provide visibility to endpoints as a base for trust-enhanched networking
• Simplified routing tables

etc.

[nicorusti]

"allowed" is also used in the CP draft:

• The :: zero-compression feature of IPv6 is NOT allowed. The feature has very limited use in a 48-bit address space and would only add more complexity.

[nicorusti]

This has been addressed in #24 and in other PRs for the other drafts.