Subject: Re: [savi] savi-dhcp-03 comments

From: "Jun Bi" <[email-masked]>
Date: Mon, 7 Jun 2010 12:01:16 +0800

Dear Christian,

Hi Christian,

Thank you very much for the detail review comments.

Here are our replies to your general comments:

1. Agree. But we are sure SLAAC address is not concerned in the current 
savi-dhcp document. For example, although a host needs to get a link-local 
address (by slaac) before get the dhcp address in dhcp-only environment, we 
didn't state how the link-local address should be bound. As we already 
proposed the framework draft text to you, we suggest the framework document 
to mention how the whole process of a dhcp-only users to get the address and 
get both the link-local and dhcp addresses bound.
In our CNGI-CERNET2 savi testbed, the equipment vendors have two CLI 
commands in savi-switch for dhcp-only environment:
   >savi link-local enable, and
   >savi dhcp snooping enable.

2. We think the detection state is necessary because the dhcp address 
assignment needs this step to finish configuration of a DHCP address. This 
state machine in the savi-dhcp draft had been proposed more than 1 year, and 
we didn't see anybody in the WG were not comfortable with it.

3. Agree not to be stated in this document, but as I said during my 
savi-dhcp ppt presentation in the Hiroshima WG meeting, we suggest this to 
be mentioned in framework document. In current savi solution(especially 
slaac), addresses with bogus prefixes will also be bound and allowed. This 
limitation should be specified.

4. We agree to add an example description of the binding process in the 
normal path. However, because the combination of normal and abnormal segment 
in the state machine will be a large number of potential paths, we think we 
have to describe the state machine based on the "current state", "the 
events", "the action", "the next state
" scheme. We think that's a reasonable description to describe state machine 
for most protocol (such as dhcp). The implementers and testers will also 
find this scheme is helpful for implementation and conformance testing.

5. Agree. Revise will be made on the mentioned sections.

6. Agree. Combination will be considered.

And thanks to your detailed comments. Corresponding modification will be 
made in the new savi-dhcp-04 version.

Best Regards,
Jun Bi
--------------------------------------------------
From: "Christian Vogt" <[email-masked]>
Sent: Wednesday, May 19, 2010 12:51 AM
To: "Jun Bi" <[email-masked]>
Cc: "Lin Tao" <[email-masked]>; "David Thaler" <[email-masked]>; 
"Jean-Michel Combes" <[email-masked]>; "SAVI Mailing List" 
<[email-masked]>
Subject: Re: [savi] Binding creation and restoration: Summary of discussion

> 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:
>
>> 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 <[email-masked]>
Date: Mon, 7 Jun 2010 09:53:26 -0700

Jun,

>> savi dhcp snooping enable.

My advise:  Take out all SLAAC-related parts from your document.  The Framework document will talk about the relationship between the SAVI solutions for SLAAC and DHCP.

> we didn't see anybody in the WG were not comfortable with it.

I am sure the state machine works fine as currently specified.  But I believe it can be simplified.

> limitation should be specified.

Right.  But the SAVI approach towards the validation of prefixes is not to use enforcement in SAVI devices, but rather to rely upon:

- Trust in DHCP servers, and

- Ingress filtering in the first-hop router.

> find this scheme is helpful for implementation and conformance testing.

Note that my comment was on the extensive sub-sectioning of the section 11, as well as on the lack of rationale.  I think you can fix this while still following your above reasoning.  My advise:  Start by simplifying the state machine to the extent possible, then do an editorial revision of section 11.

> made in the new savi-dhcp-04 version.

Perfect.  Thank you, Jun!

- Christian

---

From: "Jun Bi" <[email-masked]>
Date: Tue, 8 Jun 2010 01:14:13 +0800

Hi Christian,

Thank you for your comments again.

See below please.

--------------------------------------------------
From: "Christian Vogt" <[email-masked]>
Sent: Tuesday, June 08, 2010 12:53 AM
To: "Jun Bi" <[email-masked]>
Cc: "Lin Tao" <[email-masked]>; "David Thaler" <[email-masked]>; 
"Jean-Michel Combes" <[email-masked]>; "SAVI Mailing List" 
<[email-masked]>
Subject: Re: savi-dhcp-03 comments

> My advise:  Take out all SLAAC-related parts from your document.  The 
> Framework document will talk about the relationship between the SAVI 
> solutions for SLAAC and DHCP.
>

As I stated in last email, we are sure there is no SLAAC-address binding in 
the dhcp-03 version. There is only dhcp-assigned address binding.

> believe it can be simplified.

I guess you meant to delete the "detection" state in your last email. If you 
are OK with it, then that's good.

> Right.  But the SAVI approach towards the validation of prefixes is not to 
> use enforcement in SAVI devices, but rather to rely upon:
>

I really think the prefix configuration by RA snooping, DHCP-PD protocol, or 
manual configuration at savi-switch will be better.

It's not good to rely on ingress filtering, when savi is enabled, it's not 
sure ingress filtering is 100% enforced.

> Note that my comment was on the extensive sub-sectioning of the section 
> 11, as well as on the lack of rationale.  I think you can fix this while 
> still following your above reasoning.  My advise:  Start by simplifying 
> the state machine to the extent possible, then do an editorial revision of 
> section 11.
>

I don't quit understand how to simplify it if all the current state 
transitions (events-actions) are necessary. If you think any of them is not 
necessary, please point it out in details.

As I know, the current way is a right way to clearly describe a state 
machine in most protocols (including dhcp rfc itself): current state, events 
received, actions, next state.

Best Regards,
Jun Bi

---

From: Christian Vogt <[email-masked]>
Date: Thu, 10 Jun 2010 14:59:35 -0700

Jun,

continuing on a few points in our discussion:

> I guess you meant to delete the "detection" state in your last email. If you are OK with it, then that's good.

Hmm, I am not sure if we are on the same page.  So let me follow up a bit:  The current state machine captures every phase of DHCP-based address configuration, from the transmission of a host's DHCP Discovery message, to the final double-check DAD procedure.  My view is that such detail is not necessary for the purpose of SAVI.  We would achieve nearly the same if SAVI devices created bindings simply based on a DHCP Acknowledgment message -- without tracking any other message.  The benefits of tracking other messages are, in my opinion, very small and do not justify the extra overhead.

> I really think the prefix configuration by RA snooping, DHCP-PD protocol, or manual configuration at savi-switch will be better.
> 
> It's not good to rely on ingress filtering, when savi is enabled, it's not sure ingress filtering is 100% enforced.

You are, of course, welcome to this opinion, but the working group decided, very early in the process, that SAVI would complement ingress filtering and not replace it.  The current SAVI solution for DHCP does replace ingress filtering, and hence goes against this previous decision.  Furthermore, the replacement of ingress filtering comes at a non-negligible cost in terms of extra implementation complexity and/or extra configuration overhead.

Let's therefore take out the ingress filtering alternative from the SAVI solution for DHCP.  Vendors may implement it, but it should be part of the standard.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Thu, 10 Jun 2010 15:44:46 -0700

All:

Thanks to those of you who shared their views in the discussion on how
SAVI devices should create bindings -- control-packet-triggered or data-
packet-triggered or both.  Let's conclude then:

(1) The chairs see rough consensus for the use of data-packet-triggered 
    binding creation to minimize loss of legitimate packets.

(2) An open question is what the requirements level of data-packet-
    triggered binding creation ought to be:  a MUST, a conditional MUST,
    a SHOULD, or a MAY?

(3) SAVI will continue to use control-packet-triggered binding creation
    as its main modus operandi, as per an earlier decision of the group.

We would like to give folks until Wednesday, June 16, to comment on
above summary.  Opponents must make their case clear and convincing.
Otherwise, the working group will move ahead with the summary above.

We will discuss the open question in (2) in a separate email thread.

On a final note, please accept my (Christian's) apologies for being slow
on email within the past weeks.  I was involved in an extra, rather
work- intensive project during spring, which came on top of my
day-to-day work.  This extra project got wrapped up only recently.

- Christian, for Jean-Michel and Christian

On May 7, 2010, Christian Vogt wrote:

> 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