Mukesh,
[EMAIL PROTECTED] wrote:
[...]I am rather interested in a quick positive outcome and a win-win situation.
So are you saying that the ICMPv6 spec is talking about rate limiting the ICMPv6 traffic that is being forwarded by a router ?
From a certain perspective, a router's system architecture is certainly more complex than a host's, and there are several basic possible valid situations, with many variations. For the sake of a well documented answer, please see bellow, and bear with me, cause it may be long:
1. IP forwarding and ICMP generation is done in one processor, which also controls all interfaces. A host with multiple NICs can act as such a router.
2. IP forwarding is distributed on line cards, each line card controlling its interfaces, while ICMP generation is done in one central processor. In this case the IP stack up to and including the IP layer is distributed, but the central processor has no interfaces, therefore, it uses the line cards to output ICMP packets. IP packets may be forwarded between two interfaces on the same line card, and between two interfaces, on different line cards. So, forwarding is the most important and powerfully feature, and everything revolves around it, or is done based on it. To send ICMP packets out, the central processor forwards the ICMP packet to the appropriate output line card, similarly to one line card forwarding a packet to another line card, so internally there is no difference between forwarding and generating packets. I hope this is clear.
3. IP forwarding and ICMP are distributed on line cards, each line card controlling its interfaces, while ICMP generation takes place on each line card. Again, forwarding is the most important and powerful feature, and everything revolves around it. In some cases, the ICMP message is sent on a different interface, or line card, then the errored packet arrived. Internally, on the line card, the IP and ICMP engines can be in the same processor, or in different processors. Packets are passed internally from one processor to another almost, or identical to forwarding. So the outputting of ICMP packets generated by the line card,
looks like forwarding.
NOTE: Both example 2, and 3 are implementing a distributed IP stack, which looks line one stack from outside. Internally, every member of the stack performs some IP functions independently. The distributed functions and elements of the stack are merged together through the internal packet forwarding mechanism.
Recently a lot of debating took place around what sending ICMP packets mean? There are questions like:
a.- Does sending ICMP packets start when an errored packet is passed to the ICMP message output engine?
b.- Does sending the ICMP packet start when an ICMP message has been assembled and is ready to be sent out?
c.- Does sending the ICMP packet start when an ICMP packet has passed through the IP output engine?
e.- Does sending the ICMP packet start when it went to the wire?
When this question is asked in relationship to rate limiting, the answer can depend one what the implementation choice is:
A.- rate control the IP errored packets coming from a particular interface
B.- rate control the ICMP messages supposed to go out on a certain interface.
C.- rate control the IP traffic, with ICMP protocol field, in a generic IP traffic management as packets are going out on a certain interface,
Distinction between local or remote packets can done by adding as source address filters the local IP addresses.
D.- rate control the IP/ICMP packet, in a generic traffic management engine implemented at L2, with IP and ICMP protocols as filters, when the packet is ready to be output on the wire. Distinction between local or remote packets can be done by adding as IP source address filters filters the local IP addresses.
Which one is a correct answer? A? B? C? D? Is one more correct than the other? or all of them are equally correct?
Debating this has the potential to turn into a faith based, as opposed to technical based debate.
Then the question is it always possible to make distinction between IP/ICMP locally generated and IP/ICMP forwarded packets? Obviously in some case it is, in some it is not.
IMHO, all answers above are correct, as long as the implementations do the right thing, and have the right or desired effect on the network.
So, then what is my interpretation?
I think the ICMPv6 specification is and should be left vague enough to leave room for multiple correct interpretations, i.e. implementations.
As an IETF specification, it MUST be a protocol and not implementation standard.
If that is the case, Pekka is not alone. I also get the perception that it is talking about generating the ICMPv6 messages and NOT forwarding ICMPv6 messages. As far as I understand, rate limiting the ICMPv6 traffic being forwarded by a router is out of the scope of this spec.
I hope I explained clear enough that in some cases, there is no internal distinction between forwarded and locally sourced packets. To make the distinction, a source address filter can be applied, but is that always necessary? As it turns out, it is not, and that is OK, as long as the effect on the network is OK.
Are you ready to be constructive?
Please pardon me for saying this but it seems to me that you are not being constructive by changing the subjects line to those provocative sentences.
I am sorry if I hurt anybody's feelings.
If your concern, your vision and your target is "controlling internal ICMP message generation" and the mechanism to achieve that is the token bucket, I do not understand why does it matter to you the number of token buckets, whether it is one, or many?
Lets be clear about this. Do you agree that the spec needs to
address the rate limiting of ICMPv6 packets that are being generated by the node (host or router) and not the traffic that is being forward by a router.
I think I answered this above.
It seems that in modern routers, ICMP traffic controlled per interface, part of generic traffic control per interface, is cost effective. Cost is what ultimately counts.
The rate control can be configured to filter locally generated, all ICMP messages (local and forwarded), or only remotely generated (forwarded).
Does it matter that ICMP message generation is not controlled internally in the ICMP engine? In some cases perhaps it does, in others it does not.
But let's not lose perspective. Remember, all of this started from one simple sentence to suggest a more appropriate suggestion for rate control for routers.
Can we still address that?
[...] As far I understand (and you can explain me if I am not able to see
your point), this case is no different than a router with various type of interfaces attached.
When looked from outside, it is true. From inside it may not, but it does not matter. The per interface rate control parameters can always be translated into the appropriate granularity: line card, or node mechanism. The opposite is not true.
Moreover, we may need to be clear about what "per-node" means
in this distributed environment. To me, "per-node" should
mean per-IPv6/ICMPv6 stack.
I think your observation is right. "Per-node", in general, is IMHO clear, meaning "all interfaces".
This means, you should have the parameters configurable per line card.
We do have the two concepts of Node, and Interface in IPv6. We could define a Line Card, as a group of interfaces. Keep in mind though, for what we need,... since an interface belongs to a line card, the line card can always be inferred from the interface. So we can get away, without the line card concept.
I do not have any personal preferences about any of the choices that are being discussed.
In terms of being perfect, I agree that per interface configuration would provide a better control to the user.
But operationally, I think (and I am not always right), per interface configuration will be too complex and the extra control that it provides might not be worth the trouble.
I never saw in an IP stack, and I've seen a good number, the IP layer passing the IP packet without a reference to the incoming interface.
This of course applies to passing errored packets to the ICMP engine.
So, as this interface information is available, it can be used to reference a per interface rate control mechanism, or simply per interface rate control parameters. It is quite easy.
Ofcourse it will be easy if you are just talking about using ACLs to implement it.
Router vendors do that indeed, so you're absolutely right!
The cost of generating ICMP messages dropped with the increase of processor power, to a level, where it is more cost effective to generate ICMP packets and drop them before they're sent out in the traffic management engines, than control their generation separately from traffic management.
Regards Mukesh
Regards, Alex
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
smime.p7s
Description: S/MIME Cryptographic Signature-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
