Subject: [savi] Binding creation and restoration: Summary of discussion

From: Christian Vogt <[email-masked]>
Date: Fri, 7 May 2010 23:03:07 +0200

SAVI folks:

The working group has had a thorough discussion on how SAVI devices
should create bindings, and it seems that we are finally converging on a
solution that is commonly acceptable.  The working group co-chairs would
hence like to conclude this discussion with a consensus call.  Prior to
this, however, let's summarize the discussion to ensure that everyone is
on the same page.

Right after its inception, the working group considered two approaches
to binding creation, which have since both evolved.  These two original
approaches were:

- Pure data-packet-triggered binding creation, where a SAVI device
  creates a binding immediately upon the reception of a data packet 
  with an unbound IP source address, without requiring a prior control
  packet exchange.

- Pure control-packet-triggered binding creation, where a SAVI device
  creates bindings only upon successful completion of an address
  assignment protocol, i.e., DAD or DHCP.

Both of these approaches were found insufficient in the course of the
discussion.  Pure data-packet-triggered binding creation has a high
implementation cost.  It requires SAVI devices to take special action
based on arbitrary packets, defeating common implementation practice of
triggering special action only based on packets that match certain
filters.  Pure control-packet-triggered binding creation, in turn, is
prone to loss of legitimate packets when:

- Control packets fail to reach the SAVI device to create a binding.

- A SAVI device loses binding state.

- The network topology changes, resulting in SAVI devices not having
  binding state for hosts that now communicate through them.

Theoretically, it is possible to mitigate the drawback of control-
packet-triggered binding creation when hosts are known to directly 
connect to SAVI devices.  But such knowledge is generally unavailable.

In the meantime, two changes have taken place as the working group has
evolved its understanding of the problem space.  Firstly, the working
group has realized that SAVI devices need to operate primarily control-
packet-triggered in all cases.  Since control-packet-triggered operation
is specific to the address assignment protocol, the working group
decided to create separate documents for environments where DHCP and
SLAAC are used, respectively.

Secondly, the working group realized that data-packet-triggered
operation can be used to minimize loss of legitimate packets.  This
finding was aided by an example implementation by Fred Baker, much
referred to as the "counter technique".  Fred pointed out that one could
use a counter, and a small amount of state, to implement
data-packet-triggered actions without high implementation complexity.

Do folks agree with this summary?  Please comment by Friday, May 14.

On a final note:  Fred kindly agreed to document the example
implementation he had described, both to avoid misunderstandings, and
potentially as input to working group documents.

- Christian, for Jean-Michel and Christian

---

From: Lin Tao <[email-masked]>
Date: Fri, 14 May 2010 16:46:02 +0800

Hi, Christian:

I agree with the following summary. I have seen the draft that Fred Baker wrote,
he said he suggested that "If the SAVI Port Filter terms all fail to match , the datagram is
discarded, but a request is queued to the Table Management Process to   determine 
whether a new SAVI term needs to be added to the relevant  Port Filter."
It means that the switch ASIC must change for this feature. Maybe there are
some difficult to implement on the device, because it may increase the cost.
For the data-packet-triggered is very rarely happen, so I suggest it is optional.

Lin Tao

----- Original Message ----- 
From: "Christian Vogt" <[email-masked]>
To: "SAVI Mailing List" <[email-masked]>
Cc: "Jean-Michel Combes" <[email-masked]>
Sent: Saturday, May 08, 2010 5:03 AM
Subject: [savi] Binding creation and restoration: Summary of discussion

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

---

From: "Jun Bi" <[email-masked]>
Date: Fri, 14 May 2010 17:05:41 +0800

Hi,All

I agree with that
>>"Firstly, the working
>> packet-triggered in all cases. ", because it's implementable and low 
>> cost.

The problem is to discuss how to handle the scenario that the binding might 
be lost.

First we need to discuss in which scenario the binding entry might be lost.

>>  binding state for hosts that now communicate through them.

Then we can discuss is a scenario worthy to be handled in a high-cost 
solution or if it's just a very special case, we can just mention it in a 
section to ask operator to note and avoid it.

Then we can discuss solutions to fix those scenarios.

But in any case, I don't think data-packet triggered solution is the only 
way to handle those scenarios as a "MUST" (not every switch can implement in 
hardware), we may have several solutions to handle it and the vendors can 
chose any one of them to implement.

thanks,
Jun Bi

--------------------------------------------------
From: "Lin Tao" <[email-masked]>
Sent: Friday, May 14, 2010 4:46 PM
To: "Christian Vogt" <[email-masked]>; "SAVI Mailing List" 
<[email-masked]>
Cc: "Jean-Michel Combes" <[email-masked]>
Subject: Re: [savi] Binding creation and restoration: Summary of discussion

---

From: Dave Thaler <[email-masked]>
Date: Fri, 14 May 2010 16:32:02 +0000

I agree it's a good summary.

Just one comment on the following:
[...]
>> connect to SAVI devices.  But such knowledge is generally unavailable.

While this is true, I think the data-driven trigger should not be a MUST
(i.e. either a SHOULD, or preferably a conditional MUST with the
condition being that such knowledge is available).  That way,
if there's a scenario/device/media where it is always available,
then an implementation would still be compliant without doing the data
trigger.

-Dave

---

From: Christian Vogt <[email-masked]>
Date: Sun, 16 May 2010 18:47:10 -0500

Lin and Jun:

The working group has already concluded that the possibility of missing
bindings calls for data-packet-based binding creation.  We won't discuss
this again.  The remaining question is rather what the requirements
level for data-packet-based binding creation should be:  MUST,
conditional MUST, SHOULD, or MAY.

I reckon that sufficient arguments have been brought up against a MUST
and a MAY:  A MUST would impose unnecessary implementation cost in
scenarios where data-packet-based binding creation is known to not be
needed.  A MAY, on the other other hand, would defy the need for data-
packet-based binding creation in the general case.

This leaves a conditional MUST or a SHOULD.  I personally like Dave
Thaler's preference for a conditional MUST, since this would more
explicitly define the scenarios where omission of data-packet-based
binding creation is acceptable.  Other opinions?

- Christian

On May 14, 2010, Jun Bi wrote:

Hi,All

I agree with that

"Firstly, the working group has realized that SAVI devices need to

operate primarily control- packet-triggered in all cases. ", because

it's implementable and low cost.

The problem is to discuss how to handle the scenario that the binding

might be lost.

First we need to discuss in which scenario the binding entry might be

lost.

solution or if it's just a very special case, we can just mention it in

a section to ask operator to note and avoid it.

But in any case, I don't think data-packet triggered solution is the

only way to handle those scenarios as a "MUST" (not every switch can

implement in hardware), we may have several solutions to handle it and

the vendors can chose any one of them to implement.

thanks, Jun Bi

---

From: "Jun Bi" <[email-masked]>
Date: Tue, 18 May 2010 16:44:28 +0800

Hi Christian,

I wonder if "conditional MUST" is a formal term in RFC. 

>From RFC 2119
> SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist
> valid reasons in particular circumstances to ignore a particular item, but
> the full implications must be understood and carefully weighed before
> choosing a different course.

Considering the data-trigger is very weak to be implemented in most switches (far away for being implemented in reality), 
I don't think it's strong enough to be awarded this condition: "full implications must be understood and carefully weighed before
choosing a different course".  But it can be one of the choice and the implmentator can have any other solution with equivalent effect.

Finally, Fred Baker mentioned many times that what he propose by using counter is not called the "data trigger" solution,  please note that.
I suggest we don't mix the term when we have discussion because it will confuse people.

thanks,
Jun Bi

From: Christian Vogt 
Sent: Monday, May 17, 2010 7:47 AM
To: Jun Bi ; Lin Tao 
Cc: David Thaler ; Jean-Michel Combes ; SAVI Mailing List 
Subject: Re: [savi] Binding creation and restoration: Summary of discussion

Lin and Jun:

- Christian

  Hi,All

  I agree with that

  might be lost.

  lost.

  thanks, Jun Bi

---

From: Christian Vogt <[email-masked]>
Date: Tue, 18 May 2010 09:51:44 -0700

Jun:

Can you clarify which requirement level you suggest for data-packet- 
based binding creation?  I cannot tell from the email you sent.

On your question regarding the use of conditional MUSTs:  Conditional
MUSTs are a standard concept in RFCs.  Anything that looks like "if X
then Y MUST do Z" is a conditional MUST.

> Finally, Fred Baker mentioned many times that what he propose by using
> counter is not called the "data trigger" solution,  please note that. I
> suggest we don't mix the term when we have discussion because it will
> confuse people.

I used the term "data-packet-based binding creation", not "data
trigger".  I am assuming that this is sufficient for the purpose of this
discussion.  Note that the term will not be used in specifications
anyway; it is merely a tool to simplify our present discussion.

- Christian

On May 18, 2010, Jun Bi wrote:

> From RFC 2119:
>> SHOULD This word, or the adjective "RECOMMENDED", mean that there may
>> exist valid reasons in particular circumstances to ignore a particular
>> item, but the full implications must be understood and carefully weighed
>> before choosing a different course.
> 
> Considering the data-trigger is very weak to be implemented in most
> switches (far away for being implemented in reality), I don't think it's
> strong enough to be awarded this condition: "full implications must be
> understood and carefully weighed before choosing a different course". 
> But it can be one of the choice and the implmentator can have any other
> solution with equivalent effect.
> 
> Finally, Fred Baker mentioned many times that what he propose by using
> counter is not called the "data trigger" solution,  please note that. I
> suggest we don't mix the term when we have discussion because it will
> confuse people.
> 
> thanks, Jun Bi