Subject: RE: [Capwap] Comments on draft-cheng-capwap-classifications-01.txt

From: "Cheng Hong" <[email-masked]>
Date: Sun, 25 Jul 2004 15:03:45 +0800

Hi Pat,
 
Thanks a lot for the comments. Please see some reply inline:

<snip> 
1. Section 2.1: I have an issue with this proposal. The basic premise is
that we cannot
agree on a single model, so every vendor implements all possible
combinations.
First, I believe that the engineering resources required to design such a
box
would be cost prohibitive. Second, the number of possible combination
significantly increases the test conditions that must be performed by the
vendor. Third, it increases the code count on all devices - and the more
code
you have, the higher the potential for errors.

I would like to understand the motivation behind this proposal.

[[Cheng Hong]] I think it is quite obvious from the taxonomy draft that
different vendors have their own split methods. Also, according the to
discussion about "manageability" in the mailing list, different focus could
result in different conclusions. As you also mentioned later in this mail
that there are different customers aiming for different functions, I don't
think it would be easy for us to converge to one single split architecture
soon. And, it is almost impossible for a single way of split to meet all the
market requirements. 

[[Cheng Hong]]  In view of these, the proposal is to have the split
implemented in a standard way, so that different split could work together.
This is not to ask every vendor to implement all possible combinations. The
motivation is quite simple: a customer are free to buy AC from any vendor
even if he has WTP from different sources. This should be the reason for
forming this working group, I guess. One example of this, as described in
the draft, is that for an AC with function 1+2+3, it should be able to work
with WTP with function 2+3 and WTP with function 3, provided that 1+2+3
represents the whole MAC function. This is not asking every AC has too
implement 1+2+3. Obviously, AC could only have 1+2, and it should also work
with WTP (2+3) and WTP (3). Here the requirement is that the AC to be
implemented with module 1, 2, 3, and have well defined interface between
them. (the actual implementation of the module is still up to the vendors) I
don't think it would increase the "code count" significantly. And this
proposal is for the group to define the protocol to support the interface
between the modules.

[[Cheng Hong]] As you had attended the last IEEE802 meeting, you may already
know that there is a AP function description SG formed there.  With the IEEE
having a standard AP architecture defined, I think the above proposal
becomes more reasonable: we won't expect "infinite" kinds of split. And
therefore, we don't have to worried about the significantly increased test
conditions. 

[[Cheng Hong]] So, again, the motivation is to free the customers from being
tied down to a vendor because he already has some equipments from it.
(although that may be desired by vendors with big market share :) [[Cheng
Hong]]  

2. Section 3.1: The statement that consumers and enterprises need the
combined
benefit of all architectures does not seem correct. Customers will purchase
a product that delivers the features and performance they require. It is
not clear to me that this can only be met by supporting all possible
architectures.

[[Cheng Hong]] You are correct. The customer should have the choice. That is
what we are trying to achieve here. Since there are different ways of
architecture for the split, user should be allowed to enjoy the benefits
according to their needs. For example, a customer could have two locations
for the deployment, e.g. inside office, and outside in public area. There
would be different requirements for these two locations, and may be met by
different split architecture. The idea for the draft is that the customer
don't have to buy two AC to construct two different network for that, and he
don't have to buy expensive WTPs for both of the locations. A interoperable
design of the AC would allow the customer to have one AC to work with
different split architecture, with different WTPs deployed in different
locations.  And again, this is not proposing the support of all possible
architectures. (The customer could buy an AC that could just support these
two architectures)

3. Section 3.4: So my view is slightly different. Some customers want the
plug and play
convenience of a layer 2 approach. Furthermore, the fact that the AP is not
IP addresseable significantly reduces the risk of attack. Meanwhile, some
customers prefer the flexibility of a layer 3 approach, since it provides
them
with the ability to deploy their access points on various subnets,
eliminating
the network architectural restrictions associated with the layer 2 approach.

The security issue that is introduced with layer 3 can be overcome with
a carefully designed implementation that is tested against a variety of
network
attacks. However, I believe that you will find customers in both camps. Does
this mean that the IETF has to care about what customers will want? I guess
it
is up to us to decide.

[[Cheng Hong]] Please see the comments above. It is exactly because of the
various customer needs, we need to have the interoperable architecture so
that we don't have to case about their individual requirements. We only need
to care about a few general scenarios.  

4. Section 4.1: I disagree for the reasons listed above.

5. Section 4.2: But there are some additional deployment issues here that we
are
ignoring, such as how to protect the data on the backhaul. Perhaps it is
fine
to state that this is out of scope for the WG.

[[Cheng Hong]]  Thanks for pointing out this. Yes. There are quite some
other issues we haven't included into the draft. We are expecting to find
out more issues during the discussion. I think this would be a good
practice, especially during our re-chartering time. We need to identify the
items for the next charter. Any requirement draft based on the taxonomy
draft would help a lot. This draft is just some effort from us towards that
direction. 

6. Section 4.4: QoS can be achieved via other means, such as DS or 802.1P,
and therefore
there is not necessarily a need for sub-data channels.

[[Cheng Hong]] There are different ways of providing the QoS and security.
Comparing to pure 802.1P, the sub-data channel could have a more extensible
and clean way of achieving the goal. There are also some references to the
channel separations in the Taxonomy submissions. Maybe we could have a
thorough analysis of this in the future drafts.
 
 cheers
 
Cheng Hong

---

From: "Randy Chou" <[email-masked]>
Date: Sun, 25 Jul 2004 01:53:03 -0700

I think we should keep all the different models but also specifically list
out important features that are expected to function properly given 1+2 and
2+3.  If history is any indication from other IETF WGs, we'll have an AC and
a WTP where the only working feature is static WEP :).  I don't think
consumers will be too happy about that.  If a vendor supports a certain set
of models, I'd like to see that such models have clearly defined functions
and boundaries that don't only work with the vendor's native model.

Regards,

--
Randy

----- Original Message ----- 
From: "Cheng Hong" <[email-masked]>
To: "Pat R. Calhoun" <[email-masked]>; <[email-masked]>
Cc: "Saravanan Govindan" <[email-masked]>; "Satoshi IINO"
<[email-masked]>; "TAN, Pek-Yew" <[email-masked]>
Sent: Sunday, July 25, 2004 12:03 AM
Subject: RE: [Capwap] Comments on draft-cheng-capwap-classifications-01.txt

Hi Pat,

<snip>

 cheers

Cheng Hong

_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap