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

[Fernando Gont <[e-mail]>]

Hello, Rob,

Thanks so much for your comments! In-line.....


On 1/2/21 09:10, Rob Wilton (rwilton) wrote:
> 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.

FWIW, please note that in other documents (e.g. slaac-renum series) we 
had been asked to back this sort of claims with specific examples -- 
that's probably the reason why (as far as this co-author is concerned 
:-) ) the specific vendors/products names were provided.


That said, how about tweaking the aforementioned text to:

       For example, some contemporary high-end routers are known to use
       up to 192 bytes or 384 bytes of header.

or, even,


       For example, some contemporary high-end routers are known to use
       up to 384 bytes of header.


Please let us know which of these two would work best for you.




> 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:"

Fair enough. Will do.




> 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.

How about adding, at the end of this paragraph:

    Other platforms may have a separate software forwarding plane that is
    distinct both from the hardware forwarding plane and the control
    plane. However, the the limited CPU resources of this software-based
    forwarding plane, as well as the limited bandwidth of the associated
    link results in similar throughput constraints.

?


> 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?

I'd personally leave the two separate, as the first paragraph discusses 
the general issue, where the last para essentially discusses how this 
behavior may be triggered by EH-enabled Iv6 packets. However, I'd 
probably tweak such para as:

    If an IPv6 header chain is sufficiently long that it exceeds the
    packet look-up capacity of the router, the router might be unable to
    determine how the packet should be handled, and thus could resort to
    dropping the packet.


Please let us know if this would be acceptable.



> 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.

FWIW, I'll wait for my co-authors to weigh-in regarding this specific one.




> 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?

The rationale for this organization is as follows:

Section 6 discusses the reasons why a device may need to access 
layer-3/layer-4 information.

Section 7 discusses reasons for which EHs are problematic. One of such 
reasons is that a device may need to access layer-3/layer-4 information, 
and EHs might make that difficult. IOW, Section 6 provides the rationale 
for which Section 7.1 is an issue.



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

I'd believe that that would be incorrect for the following reasons:

* EHs pose a challenge when layer-4/layer-3 information is needed. This 
*can* be achieved in a practical way.

* If you need app-layer information, there's essentially not much that 
you can do to address this. (e.g., a device would need to do 
fragment-reassembly, TCP reassembly, etc.). I don't think this one can 
be achieved in a practical way without a significant throughput penalty 
(among others) -- if at all possible.




> 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.

Done.




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

Will do.


Please do let us know your thoughts about the proposed edits, such that 
we can rev the document accordingly.

Thanks!

Regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492