Subject: RE: [Capwap] REQ3: WTP MAC independence

From: "Saravanan Govindan" <[email-masked]>
Date: Tue, 12 Apr 2005 09:42:35 +0800

Hi Mani,

Just for my understanding, this objective should highlight that
'split-MAC' refers to designs where both MAC and other AP functions
(data aggregation, STA state information etc.) are split across AC and
WTPs.

So would the following text cover this?

----XXXX----
Classification: General

Description:
The CAPWAP protocol must not be specified for a particular MAC or WTP
design. It should be compatible with the major designs detailed in the
Architecture  Taxonomy, namely local-MAC and split-MAC WTPs. 

Protocol Requirement:
WTP vendors must not be bound to a specific MAC or WTP design.

Motivation and Protocol Benefits:
This requirement is to ensure that WTP vendors have sufficient
flexibility in selecting the type of MAC or WTP design that they
consider best for  deployments. 

Relation to Problem Statement:
This requirement is based on WG discussions that have determined to be
important for CAPWAP.
----XXXX----

Cheers,

Saravanan

> -----Original Message-----
> From: Mani, Mahalingam (Mahalingam) [mailto:[email-masked]] 
> Sent: Tuesday, April 12, 2005 8:46 AM
> To: Saravanan Govindan; [email-masked]
> Subject: RE: [Capwap] REQ3: WTP MAC independence
> 
> The objective should, still, reference the architecture 
> taxonomy's guideline; normative though it may not be as an 
> informational; to provide near-close interpretation to what 
> constitutes split-MAC. I am still inclined to think split-AP 
> would have been a better terminology (in an attempt to 
> replace energetically the use of AP term from the draft to 
> WTP - we have lost out on AP terminology - equating AP to 
> local-MAC WTP) to provide a less schizophrenic interpretation 
> of split.
> 
> -mani
> ======
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Saravanan Govindan
> Sent: Saturday, April 09, 2005 11:09 PM
> To: [email-masked]
> Subject: [Capwap] REQ3: WTP MAC independence
> 
> Classification: General
> 
> Description:
> The CAPWAP protocol must not be specified for a particular 
> MAC. It should be compatible with both local-MAC and split-MAC WTPs. 
> 
> Protocol Requirement:
> WTP vendors must not be bound to a specific MAC.
> 
> Motivation and Protocol Benefits:
> This requirement is to ensure that WTP vendors have 
> sufficient flexibility in selecting the type of MAC that they 
> consider best for deployments. 
> 
> Relation to Problem Statement:
> This requirement is based on WG discussions that have 
> determined to be important for CAPWAP.
> _______________________________________________
> Capwap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/capwap
> 
> 
> 
_______________________________________________
Capwap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/capwap

---

From: Inderpreet Singh <[email-masked]>
Date: Mon, 11 Apr 2005 22:26:44 -0400

I prefer the previous wording.  Furthermore, if I am not mistaken, the
intent of the requirement as initially suggested by Pat was more
regarding the MAC implementation vendor, rather than the MAC
functional type as defined in the Taxonomy.

Section 5.1.11 of draft-ietf-capwap-objectives-01.txt already
specifies that the protocol must support a negotiation of capabilities
with regard to MAC type, namely split or local and already references
the Taxonomy document.

Thanks

Inderpreet

---

From: Partha Narasimhan <[email-masked]>
Date: Mon, 11 Apr 2005 21:02:31 -0700 (PDT)

Now I am confused. If the requirement is not suggesting any slant towards 
either local MAC or split MAC, then what exactly does "MAC" mean in the 
text? If it is referring to split-MAC vs local-MAC, then that, as Inder 
points out, is already covered somewhere else in the draft. Why do we need 
redundant requirements?

Also, frankly I would remove the WTP or AC and make the text cover both 
(assuming we can first reach some consensus on the current discussion on 
whether one or more requirements is redundant or not). Is there any reason 
why interoperability requirements should work one way, but not necessarily 
the other way? It seems cleaner to have it work both ways.

Thanks
partha

---

From: "Pat Calhoun" <[email-masked]>
Date: Tue, 12 Apr 2005 06:18:46 -0700

My original wording was that a given protocol, or proposal, should not be
bound to a specific MAC implementation. The intent was not to discuss the
different architectures, but to ensure that the end proposal was not
restrictive to a single MAC implementation.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> [mailto:[email-masked]] On Behalf Of Partha Narasimhan
> Sent: Monday, April 11, 2005 9:03 PM
> To: Inderpreet Singh
> Cc: Saravanan Govindan; Mani, Mahalingam (Mahalingam); 
> [email-masked]
> Subject: Re: [Capwap] REQ3: WTP MAC independence
> 
> Now I am confused. If the requirement is not suggesting any 
> slant towards either local MAC or split MAC, then what 
> exactly does "MAC" mean in the text? If it is referring to 
> split-MAC vs local-MAC, then that, as Inder points out, is 
> already covered somewhere else in the draft. Why do we need 
> redundant requirements?
> 
> Also, frankly I would remove the WTP or AC and make the text 
> cover both (assuming we can first reach some consensus on the 
> current discussion on whether one or more requirements is 
> redundant or not). Is there any reason why interoperability 
> requirements should work one way, but not necessarily the 
> other way? It seems cleaner to have it work both ways.
> 
> Thanks
> partha
> 
> >> (data aggregation, STA state information etc.) are split across AC 
> >> and WTPs.
> >>
> MAC or WTP 
> >> design. It should be compatible with the major designs detailed in 
> >> the Architecture  Taxonomy, namely local-MAC and split-MAC WTPs.
> >>
> >> Protocol Requirement:
> taxonomy's 
> >>> guideline; normative though it may not be as an informational; to 
> >>> provide near-close interpretation to what constitutes 
> split-MAC. I 
> >>> am still inclined to think split-AP would have been a better 
> >>> terminology (in an attempt to replace energetically the use of AP 
> >>> term from the draft to WTP - we have lost out on AP terminology - 
> >>> equating AP to local-MAC WTP) to provide a less schizophrenic 
> >>> interpretation of split.
> >>>
> >>> -mani
> >>> ======
> >>>
> >>> The CAPWAP protocol must not be specified for a 
> particular MAC. It 
> >>> should be compatible with both local-MAC and split-MAC WTPs.
> >>>
> >>> Protocol Requirement:
> >>> flexibility in selecting the type of MAC that they 
> consider best for 
> >>> deployments.
> >>>

---

From: Partha Narasimhan <[email-masked]>
Date: Tue, 12 Apr 2005 08:57:26 -0700 (PDT)

This is again something that is covered, IMHO, more broadly in REQ1 
(assuming the WG can agree that this is indeed required). Which would make 
REQ3 a subset of REQ1. I dont see a need to call out individual components 
of a WTP or AC when another requirement addresses the 
interoperability issue.

By the same token, my opinion is the same with REQ2 that it is a subset of 
REQ1. In fact, one could even argue that calling out REQ2 with the 
proposed text forces WTP or AC vendors to stop any future feature 
development that might break interoperability and, hence, risk violating 
REQ1.

Thanks
partha