Subject: Re: Hop-by-Hop Extension Header processed in Slow Path?

From: Roland Bless <[email-masked]>
Date: Fri, 04 Feb 2011 13:21:22 +0100

Hi,

Christopher Morrow wrote:
> My feeling is this:
> hop-by-hop processing will happen in slow-path (if you permit it to
> happen at all), you can't build a router today with an asic that'll
> know how to handle options which are created in the future :(

while the latter is surely true, I don't think that this
argument precludes to implement fast path processing
of at least _some_ HbH options. I think that the current
implemented strategy to simply pass all HbH options
to the slow path CPU is broken.

I'm not sure whether it is feasible, but couldn't the
Fast Path (ASIC) at least check for:
- known options to be processed in the fast path, e.g.,
  some CONEX info field
- known options to be processed in the control plane,
  i.e., punt packet to control path (slow path CPU),
  e.g., some to intercept packets with a specific
  router alert option
- bypassing unknown options (depending on the specified
  actions) in the fast-path

So some (not all) _basic_ header extension processing code
should be down in the fast path (like forwarding of non-supported
or "non-interesting" hop-by-hop options) while more complex
processing can surely stay up in the slow path.
I have the impression that we will sacrifice the possibility of
future useful IPv6 extensions due to some existing
implementation limitations.

Regards,
 Roland

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 4 Feb 2011 10:27:31 -0500

> - known options to be processed in the fast path, e.g.,

which options? how often would you expect this list to update? routers
live in the network for ~7 years or so, in large networks. ASIC
updates mean very expensive (equipment, personnel, sla) changes are
required.

>  actions) in the fast-path

and hopefully with a consistent decision on which goes where here? I'd
hate for (for example) Cisco to turn left while Juniper turns right...
this also seems complex. Again, just providing a knob (and accepting
that it will happen) that the HBH options may just be ignored in the
public network may terminate this discussion completely.

-chris

---

From: Vishwas Manral <[email-masked]>
Date: Fri, 4 Feb 2011 09:53:46 -0800

Hi Roland,

The problem is not just about known options here, like I mentioned
earlier. A structure where there is a list which needs to be walked
serially and no fixed place for an information, it is bad for the fast
path.

I have mentioned cases for how bad it can get for IPv6. One good thing
IPv6 does is it defined the order of options.

If we want to process connex or some particular option, we could
process it. However there may need to be some assumptions like, the
option is the first in the list of options or any such thing.

Thanks,
Vishwas

On Fri, Feb 4, 2011 at 4:21 AM, Roland Bless <[email-masked]> wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 4 Feb 2011 17:14:45 -0500

> updates mean very expensive (equipment, personnel, sla) changes are

Someone reminded me off-list to be clear about what the problem is...
Any packet that requires hop-by-hop behavior is a problem. If a
backbone router has to attempt to stream packets off a production
interface and into the RE/RP/PRP, the router will fall over.

So, the operator(s) are left with 2 real options:
  1) drop all packets NOT icmpv6, tcp, udp (drop all other extension headers)
  2) ignore any extension header NOT icmpv6, udp, tcp

It would be grand if router vendors (Juniper, Cisco, Force10, Extreme,
Foundry, Huawei, etc) would provide a knob on all of their platforms
that said:

  hbh-options [ignore|drop]

This would allow all network operators (enterprise, datacenter,
backbone) to decide how to handle traffic with hbh options.  I'm sure
someone at the vendor of your choice could also add in options to
drop/ignore by type of option, though that seems more brittle.

(I hope this is more clear :) )

-Chris

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 4 Feb 2011 17:40:02 -0500

Hi Chris,

> interface and into the RE/RP/PRP, the router will fall over.

I fully agree with you.

>   hbh-options [ignore|drop]

The ignore option was what I proposed in Section 3.2 of

http://tools.ietf.org/html/draft-krishnan-ipv6-hopbyhop-05

but dropping should be something that an operator should be able to 
enable as well.

Cheers
Suresh

---

From: Roland Bless <[email-masked]>
Date: Mon, 07 Feb 2011 10:31:57 +0100

Hi Chris,

> updates mean very expensive (equipment, personnel, sla) changes are

Which options depends on the supported or configured options.
I didn't mean to hard code the list into the ASIC, but the list
should be configurable, so no need to update the ASIC once the
basic mechanisms for HBH options are available. For example if
only some router alert option values are of interest, those should
be configured in the aforementioned list, everything else would
be bypassed in the fast path.

> this also seems complex. Again, just providing a knob (and accepting

I guess that's the problem of earlier specs that provide too little
guidance for implementers, IMHO  that's at least the case for the
Router Alert Option.

> public network may terminate this discussion completely.

Yes, maybe.

Regards,
 Roland

---

From: Roland Bless <[email-masked]>
Date: Mon, 07 Feb 2011 11:44:41 +0100

Hi Vishwas,

> serially and no fixed place for an information, it is bad for the fast

I see.

> option is the first in the list of options or any such thing.

Personally, I'm not looking for a new option, but I was wondering
about Conex trying to redefine/claim common IPv6 header bits for
their purpose, which is IMHO worse than using some HbH option.
In NSIS we suffered a lot from the Router Alert Option problems...
If the current extension mechanisms of IPv6 need some fixes to
allow for fast path processing and to be useful in the future at
least, someone may consider working on this out...

Regards,
 Roland

---

From: John Leslie <[email-masked]>
Date: Mon, 7 Feb 2011 07:33:45 -0500

Roland Bless <[email-masked]> wrote:
> their purpose, which is IMHO worse than using some HbH option...

Disclaimer: I am a co-author of one of the ConEx drafts; but I make no
claim to speak for anyone else -- least of all my co-authors!

   I _think_ we're looking at the Flow Label field. Let me outline my
understanding of that field --

RFC 2460 states that the Flow Label field is to be set by the source:
] 
] 6.  Flow Labels
] 
]  The 20-bit Flow Label field in the IPv6 header may be used by a
]  source to label sequences of packets for which it requests special
]  handling by the IPv6 routers, such as non-default quality of service
]  or "real-time" service.  This aspect of IPv6 is, at the time of
]  writing, still experimental and subject to change as the requirements
]  for flow support in the Internet become clearer.  Hosts or routers
]  that do not support the functions of the Flow Label field are
]  required to set the field to zero when originating a packet, pass the
]  field on unchanged when forwarding a packet, and ignore the field
]  when receiving a packet.
] 
]  Appendix A describes the current intended semantics and usage of the
]  Flow Label field.

   Note Appendix A is "current intended semantics" and is clearly subject
to change.

   Appendix A "currently" calls for:
] 
]  A flow label is assigned to a flow by the flow's source node.  New
]  flow labels must be chosen (pseudo-)randomly and uniformly from the
]  range 1 to FFFFF hex.  The purpose of the random allocation is to
]  make any set of bits within the Flow Label field suitable for use as
]  a hash key by routers, for looking up the state associated with the
]  flow.

   Since Appendix A calls for "pseudo-random" and section 6 insists that
"most" routers must ignore the field and pass it unchanged, at first blush
ConEx-aware senders could put something there and expect it to survive
the trip through a number of not-ConEx-aware routers. ;^)

   Note that RFC 1883, which suggested that routers "opportunistically"
"set up flow handling state" is now quite obsolete (the field doesn't
even match!); and even 1883 made no suggestion that a router might
legitimately _change_ the flow label.

   (I suppose technically a NAT might play with flow-label, since the
definition calls for a flow to be 
] 
] uniquely identified by the combination of a source address and a
] non-zero flow label

but I have no reason to believe any existing IPv6 NAT does such a thing.)

   IMHO, Appendix A of RFC 2460 was pining-for-the-fjords when RFC 2460
was published in 1998. However, we need to consider RFC 3697, published
in 2004. (It is standards-track, but I don't know of any implementations.)

   RFC 3697 specifies:

- The Flow Label value set by the source MUST be delivered unchanged 
  to the destination node(s)

- IPv6 nodes MUST NOT assume any mathematical or other properties of 
  the Flow Label values assigned by source nodes.

- Router performance SHOULD NOT be dependent on the distribution of the 
  Flow Label values.  Especially, the Flow Label bits alone make poor 
  material for a hash key.

====

   Thus it would seem that ConEx-aware senders could put a value in
Flow label, reserving several bits that could be changed by ConEx-aware
routers (and more importantly by ConEx policers) without changing the
flow _identity_ as seen by ConEx-aware devices.

   I'd like to see some discussion of this. IMHO, 6man is a better place
for the discussion than ConEx, since ConEx is concerned with the meaning
of bits more than transport of them.

--
John Leslie <[email-masked]>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 08 Feb 2011 10:00:08 +1300

Hi John,

First off, forget what the Appendix of RFC 2460 says. It's not normative.

So, the current rules are in RFC 3697. They certainly don't
allow any kind of semantics in the bits of the flow label (in
the absence of a signalling mechanism):

> IPv6 nodes MUST NOT assume any mathematical or other properties of 

Then:

>> reserving several bits that could be changed by ConEx-aware
>> routers 

Changing any bits is forbidden by RFC 3697.

We are discussing draft-ietf-6man-flow-3697bis-00.txt, which will
(if approved) replace RFC 3697. It doesn't allow encoding any kind
of semantics either, or mutability, but of course it's open for debate
in the WG. I suggest reading that draft as the next step.

Regards
   Brian Carpenter