> Martin Millnert <mailto:mar...@millnert.se> > 31 May 2013 11:14 > Hi, > > On 31 maj 2013, at 09:37, Sheng Jiang <jiangsh...@huawei.com> wrote: > <snip> > <snip> > > Extra headers is a no-go for efficient FIB-lookup and thus a waste of > time in many aspects to standardize. > > My 2 cents. > > Regards, > Martin
I was suggesting looking at using a tag option within an existing header (the hop by hop header), which theoretically is already processed by all nodes along the path. So new options rather than a new header. Whether we encode these additional semantics via an address match, or a DSCP match, or a hop by hop approach, I agree the tag has to be found and parsed and processed, so it would seem sensible to me to avoid unnecessarily overloading existing semantics and instead to encode it in the position in the packet where you'd expect to find something meant for hop by hop processing i.e. the hop by hop header. If operators don't want to process the hop by hop header in the network core for whatever reason, draft-carpenter-6man-ext-transmit already proposes allowing skipping it. The alternatives: tagging in the address structure, creating tunnels, and tagging by encapsulation e.g. MPLS, also have significant pros and cons for both parsing and forwarding. But why are people coming up with these schemes for encoding semantics in the address prefixes in the first place? That's what I'd like to understand first and foremost: what lack of functionality is motivating/forcing these people to adopt such schemes? regards, RayH -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
