On Fri, 12 Jun 2020 at 20:12, Andrey Kostin <ankost@podolsk.ru> wrote:
Sorry for jumping in in the mddle of discussion, as a side note, in case of IPIP tunneling, shouldn't another protocol type be utilized in MAC header? As I understand, in VXLAN VTEP ip is dedicated for this purpose, so receiving a packet with VTEP DST IP already means "decapsulate and lookup the next header". But in traditional routers loopback IPs are used for multiple purposes and usually receiving a packet with lo0 IP means punt it to control plane. Isn't additional differentiator is needed here to tell a router which type of action it has to do? Or, as alternative, if dedicated stack of IPs is used for tunneling, then another lookup table is needed for it, isn't it? And now looks like we are coming to the header structure and forwarding process similar that we already have in MPLS, only with different label format. Please correct me if I went off track somewhere in this logical chain.
I don't think new etherType is mandatory by any means. Biggest gain is security. SRv6 will necessarily have a lot of issues where unauthorised packet gets treated as SRv6, which is much harder in MPLS network. Many real-life devices work very differently with EH chains (with massive performance drop, like can be 90%!). JNPR Trio will parse up-to N EH, then drop if it cannot finish parsing. NOK FP wil parse up-to N EH, then forward if it cannot finish parsing (i.e. now it bypasses TCP/UDP denies, as it didn't know it is TCP/IP, or it could have SRv6 EH, which it couldn't drop, as it didn't know it had it). But in terms of the big MPLS advantage, of having guaranteed exact match lookups on small space, compared to LPM lookups on large space. We could guarantee this in IPIP tunnels too, without having any difference in the headers, other than obligation/guarantee that all LSR packets are IPIP encapsulated with a small amount of outer packet DADDRs. -- ++ytti