On 22/09/10 3:56 PM, "Mikael Abrahamsson" <swm...@swm.pp.se> wrote:
> On Wed, 22 Sep 2010, Hesham Soliman wrote:
>
>> => But you're saying that as an operator need, when in fact your rationale
>> is to reduce vendor code. Is any vendor complaining about this? Is this an
>
> Well, yes, I want to reduce vendor code and to simplify the deployment. In
> my deployment model there also is no dynamic happening on the ISP-WAN
> segment, so there is little need for ND.
>
> There are very few vendors that support at all the SAVI L2 functions
> needed, I want to ease the implementation.
>
> But yes, you're correct, this is to simplify the code so there is shorter
> time to market and less test cases for us to run to make sure the vendor
> software runs properly. I'm also hoping it'll make the devices cheaper.
=> Ok, thanks for explaining that. Two comments:
1. Having worked for both vendors and operators, I can assure you that you
will not reduce the price of the products based on this optimision.
2. It is clear to me that this is not something for a specific deployment,
this is purely a business support decision. I'm not saying you're wrong to
try this, but I have my doubts about creating standards based on short term
business objectives. It is short term, because if you wait you will get your
products.
Based on my IETF experience I would say you're more likely to get the "new"
products before you can get a new standard passed and implemented.
>
>> I'm trying to understand where the problem is.
>
> Multiple levels. ND is one more thing to go wrong. The less functionality
> needed, the easier it is for all involved.
=> Well, the question is whether it is needed functionality. You say you
don't need it, which is fine, but you have to admit that you're losing
reliability here. It's up to you to make that trade-off in your deployment,
but as a standards organisation, we have a different trade-off to make.
Whenever two proposals become so vastly contradictory, there must be very
strong justification IMO. I see the justification above as a short term
business need and is not based on the nature of the deployment, it's based
on product availability.
I don't think this is a good reason but I'll let others say what they think.
Static filtering is easier than
> dynamic inspection and filtering based on that. It means less punting
> packets to CPU in the L2 devices, less DoS vectors, less everything.
=> Dynamic filtering is not done by hand, it's done in code and once it's
there it's there. There is initial effort by the vendor and that's it.
Hesham
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
