Subject: Re: [savi] Consensus call on "unregistered" source addresses

From: Lin Tao <[email-masked]>
Date: Tue, 04 Aug 2009 17:34:12 +0800

Hello, Everyone!

I'm Sorry, I havn't taken part in the significant discuss for many months.

I agree Eric's viewpoint that the first L2 switch should be savi-focus switch.
The completely theoritical problem in most environments also should be solve
in the future, but not now. IPv6 must have low cost and easy implementation
in L2 switch.

I wonder that Why should  we consider the unregistered source addresses.
If these addresses is permit, Why did we create the binding table?

And I wonder that Why should the first data packet(not control packet)
trigger binding process. If this data is permit, how does the switch ASIC 
be set in the input process? How to set a packet hasn't met any source
filter ACL to send to CPU?

Could anyone release me from these puzzle? Thank you very much.

----- Original Message ----- 
From: "Eric Levy-Abegnoli" <[email-masked]>
To: "Erik Nordmark" <[email-masked]>
Cc: "SAVI Mailing List" <[email-masked]>; "Christian Vogt" <[email-masked]>
Sent: Wednesday, July 29, 2009 3:45 AM
Subject: Re: [savi] Consensus call on "unregistered" source addresses

Erik Nordmark a écrit :
> Eric Levy-Abegnoli wrote:
>> Erik,
>> Erik Nordmark a écrit :
>>> Christian Vogt wrote:
>>>> Folks -
>>>>
>>>> As announced earlier, we will have a consensus call on how SAVI 
>>>> devices
>>>> should treat source addresses for which no configuration signaling was
>>>> seen.  Consensus questions for this were proposed on July 8, and the
>>>> feedback received from the working group indicates that those are OK.
>>>>
>>>> I would hence like to initiate the consensus call.  To participate in
>>>> the consensus call, please answer by Sunday, July 19, the following 
>>>> two
>>>> questions (A) and (B), using one of the two possible answers provided
>>>> for each question:
>>>>
>>>> (A) In networks where SLAAC is permitted for address configuration, 
>>>> how
>>>>     should a SAVI device treat packets with a source address for which
>>>>     neither a successful DAD procedure nor a DHCP assignment was seen?
>>>>
>>>>     (A1) Discard the packet
>>>>     (A2) Forward and optionally log the packet
>>>
>>> I think the question was malformed for the following reasons.
>>>
>>> *IF* SLAAC is permitted, then by definition the host can pick 
>>> whatever address it wants. DAD as defined is not a reliable 
>>> protocol, thus pretending it is the way a host *registers* a SLAAC 
>>> address makes no sense. For instance, if 802.1D bridges wait for 30 
>>> seconds before enabling a Ethernet port, then no DAD packet would be 
>>> seen on the network.
>>>
>>> Thus I think the case when the the admin wants to only allow 
>>> registered addresses then SLAAC can not be used; DHCPv6 would need 
>>> to be used as the assignment/registration protocol.
>>>
>> Maybe it's a matter of wording. In the SLACC case, the host does not 
>> *register*,  however it is not unreasonnable to expect that the first 
>> hop (L2 switch)  have seen a binding for it.
>
> Which protocol reliably established that binding?
Did you read "reliably established"? None, so? We can spend years 
solving a problem that is a completely theoritical problem in most 
environments. Or we can try to do with what we have.
DAD is theoritically broken. I mean DAD, no savi. If your DAD packet is 
lost, you never know that your address is duplicate. - in theory, it 
could be- *exactly* in the case that you describe below, you don't know 
neither. Does that prevent node to test duplicate in most cases? no.
It would be great to have a declarative reliable protocol. Not sure we 
need yet another one though. InverseND would do. But the truth is, 
getting anything like this into the host is going to take a decade, and 
only if there is a buyout. I find the charter very wise from that 
regard: no new protocol allowed.
 
>
>> In a sense, it's not very different from RPF. If you don't have a 
>> return path to it, it is suspicious. Not broken because the nexthop 
>> will do address resolution on the reverse path, but suspicious 
>> because bindings are announced in a fairly redundant way (DAD * n, 
>> NA, NS*3)
>
> Standard IPv6 DAD does 1 DAD probe and nothing more.
> The proposal I've seen is to only rely on that DAD probe.
>
One DAD is the default,.certainly not a MUST. So I don't see anything 
wrong in recomemnding to use a higher value in a savi setup. As fas as 
using more than DAD, well, it's still opened, isn't it?
>> It really takes some specific cases to not see any binding prior to 
>> forward a host traffic. And then it's a matter of policy: Your 
>> example is the one of a non-savi switch (your 802.1D bridge) 
>> connected to a savi switch. The policy could be to forward by default 
>> in this case.
>
> My primary example is SAVI/802.1D switches which leave the port in 
> blocked or learning state for a while thereby dropping the DAD probe.
>
> For the case where there is a legacy switch between the host and the 
> SAVI switch I don't think we want to completely disable SAVI; that 
> would severely limit the utility of SAVI (and I really want to see 
> SAVI enabled by default everywhere) in common topologies. For instance 
> corporate IT organizations that de-fact encourage folks to have small 
> unmanaged switches in their office by charging per Ethernet drop.
>
> I think the WG should figure out how to handle such cases in a robust 
> manner.
I am not ruling that out. But a non-savi switch, not doing 
authentication at layer2, connected to a savi switch is the hard case. I 
would not pre-req solving it to make progress on the other cases.
Eric
>    Erik

_______________________________________________
savi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/savi

---

From: "Jun Bi" <[email-masked]>
Date: Tue, 4 Aug 2009 22:00:15 +0800

Hi Tao,

Thank you for your message. The advice from equipment vendors are valuable.

I heard from another engineer that in current Ethernet switch structure,
there are two tables:
1)first table is used to snoop packets for CPU actions (named as slow path: 
to send matched packets to CPU).  The table size is usually smaller (because 
it only needs to match speified L2/L3 protocol type,and total number of 
ptotocol types is limited etc)
2)If the packet doesn't match the first table, then the packet will be 
handled in the fast path for forwarding, then before the acutal forwarding, 
the 2nd table is used for data packets filtering. The table size is usually 
longer.(because the IP,MAC, etc has to been searched here).

They think if the the first table is used for data packet triggered CPU 
actions (if uses the 2nd table could be only used in fast path to trigger 
the packet dropping, there will be no slow path to send the packet to CPU 
here), then the source address must be installed into the first table,then 
the total number of source address could be bound will be reduced (because 
the size limitation of the first table).

thanks,
Jun

----- Original Message ----- 
From: "Lin Tao" <[email-masked]>
To: "Eric Levy-Abegnoli" <[email-masked]>; "Erik Nordmark" 
<[email-masked]>
Cc: "SAVI Mailing List" <[email-masked]>; "Christian Vogt" 
<[email-masked]>
Sent: Tuesday, August 04, 2009 5:34 PM
Subject: Re: [savi] Consensus call on "unregistered" source addresses

Hello, Everyone!

I agree Eric's viewpoint that the first L2 switch should be savi-focus 
switch.
The completely theoritical problem in most environments also should be solve
in the future, but not now. IPv6 must have low cost and easy implementation
in L2 switch.

----- Original Message ----- 
From: "Eric Levy-Abegnoli" <[email-masked]>
To: "Erik Nordmark" <[email-masked]>
Cc: "SAVI Mailing List" <[email-masked]>; "Christian Vogt" 
<[email-masked]>
Sent: Wednesday, July 29, 2009 3:45 AM
Subject: Re: [savi] Consensus call on "unregistered" source addresses

---

From: Lin Tao <[email-masked]>
Date: Wed, 05 Aug 2009 17:33:27 +0800

Thank you very much. Maybe some switch chip can do that like you say.
In that way, the chip couldn't perfectly support the Data Triggered CPU
actions.
On the other hand, I have seen discussion that data packet is used to triggered
DAD probe. If the data that triggered to CPU triggered a DAD probe,
and the source IP address is considered as a  forged address, how to deal 
with it? If the ACL of this source IP address is set, the packet match this ACL
will be discard, we can prevent the latter packet from impact the CPU. But it
will occupy on ACL entry that is finite resource.