Re: [c-nsp] LDPv6 Census Check

[Saku Ytti <saku () ytti fi>]

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