[v6ops] AD review of draft-ietf-v6ops-ipv6-ehs-packet-drops-03

["Rob Wilton (rwilton)" <[e-mail]>]

Hi,

Here is my AD review of draft-ietf-v6ops-ipv6-ehs-packet-drops-03.

Overall, I found the document pleasant to read and informative, so thank you for writing this up.  I have a few minor comments for the authors to consider:

5.  Packet Forwarding Engine Constraints

   NOTE:
      For example, contemporary high-end routers can use up to 192 bytes
      of header (Cisco ASR9000 Typhoon) or 384 bytes of header (Juniper
      MX Trio).
      
Please can you remove the vendors/products here and report the information more generally.  I suspect that the limitation depends on the switch ASIC, and is somewhat likely to vary by linecard, even for the same platform.


   NOTE:
      Section 6 discusses some of the reasons for which a contemporary
      router might need to access layer-4 information to make a
      forwarding decision.

This is purely editorial, but I would probably have just tacked this on to the previous paragraph rather than have it as a separate "NOTE:"      

   Historically, some packet forwarding engines punted packets of this
   form to the control plane for more in-depth analysis, but this is
   unfeasible on most contemporary router architectures as a result of
   the vast difference between the hardware forwarding capacity of the
   router and processing capacity of the control plane and the size of
   the management link which connects the control plane to the
   forwarding plane. 

I'm not sure whether this is worth clarifying, but I think that this is simplifying contemporary forwarding architectures somewhat:  Platforms may have a separate software forwarding plane that is distinct both from the hardware forwarding plane and the control plane.  E.g., IPv4 options might be processed in a software forwarding plane rather than in the hardware or the control plane.  However, the key point that the CPU and network bandwidth to the CPU are limited resources is entirely valid.

   If a hardware forwarding engine on a contemporary router cannot make
   a forwarding decision about a packet because critical information is
   not sent to the look-up engine, then the router will normally drop
   the packet. 

   If an IPv6 header chain is sufficiently long that it exceeds the
   packet look-up capacity of the router, the router could resort to
   dropping the packet, as a result of being unable to determine how the
   packet should be handled. 
   
These two paragraphs feel like they are saying the same thing.  Perhaps they should be amalgamated?

5.1.  Recirculation

I was surprised by this section, although I'm not disputing it.  I've heard of forwarding architectures recirculating tunnelled packets, but I've not heard of this recirculation for processing each and every IPv6 extension headers.



6.  Requirement to Process Layer-3/layer-4 information in Intermediate
    Systems
    
For the last 2 sub-sections, this section also covers why extension headers are problematic, but not for the other sections.  Hence wondering if this is structured in the best way?  E.g., would it be better if the implications for sections 6.4 and 6.5 were discussed in section 7 instead?

In addition, should the title of this section (6) indicate that it also covers application layer information?


6.5

   As a result, whether because of the challenges represented by
   extension headers or because the use of IPv6 extension headers has
   not been explicitly allowed, packets employing IPv6 extension headers
   are often dropped by network firewalls. 
   
I found this paragraph slightly harder to parse that perhaps needs be, and
possibly it might be easier reversed:

   As a result, packets employing IPv6 extension headers are often dropped
   by network firewalls, either because of the challenges represented by
   extension headers or because the use of IPv6 extension headers has not
   been explicitly allowed.


Nits:      
  maybe -> may be
  "e.g. " => "e.g., "

Regards,
Rob