Subject: [Capwap] The discussion of WTP Id issues and so on

From: young <[email-masked]>
Date: Thu, 25 Jun 2009 12:00:42 +0800

Hi，Abhijit：

Thanks.
Check my comments inline which is identified by [Richard].
To Dan: Kindly give your opinion to the discussion of question 3, as 
You ever raised a similar issue.

1.  WTP Id issues
[Abhijit] WTP Profile.  While it's possible to use the
(VendorId+SerialNumber), I really suspect that a MAC address is more
appropriate and something most vendors will end up using. To your point
about the Base MAC Address not being a MUST, RFC 5415 seems ambiguous
about it. 
Note that while the RFC specifically sates the other types MUST or MAY
be included, it doesn't say so for Base MAC Address.  It says the Base
Mac Address may be assigned but says nothing about whether it MUST or
MAY be included in the Board Data Type.
Another option is the Base BSSID. Again although the spec only says it's
recommended, I suspect most vendors will have it available.
Could we add text to the effect that one can use either the
(VendorId+SerialNumber) as you suggested or the Base MAC Address or Base
BSSID if it's available?

[Richard] As we could not offer two options (BAC Mac or
(VendorId+SerialNumber))
to identify a WTP when we design the MIB, we have to choose one way between
these two.
As Base MAC Address is not being a MUST, I suggest we use
VendorId+SerialNumber.
How about this way?

2.  Model number issue
[Abhijit] WTP Virtual Interfaces:  I still don't see the reason to include
the
Model number in the WTP Profile. The number of virtual interfaces
depends on the number of active radios. The WTP specifically includes
this information in the WTP Descriptor:
So, there is no need for the Model number here.

[Richard] To manage the WTPs, the basic operation process is: Operator has
to prepare the configuration before WTPs connect to AC. The configuration of
interface (radio) is an important step. Operator need know how many radios a
WTP has.
At the time (Before WTP contact with AC), AC could not know any interface
info which are in the WTP Descriptor (here is key point). While the module
number could tell that the operator (AC system) how many radios a WTP could
have, and it could
trigger the system to automatically create WTP virtual Radio interfaces
before WTP contact with AC. So it could let the operator have chances to
configure the "Virtual" radios through its ifIndex.
This is the reason that the Model number is need here. Otherwise, there is
no way to let the operator prepare the configuration of radio interface
before
WTP contact with AC.
Suggest you go through the section 8 (example) in the draft.
 
3.  Relationship to IF-MIB.  
[Abhijit] I went through the slides you sent. I see
that IF there is a desire to have a common handler, having the ifIndex
persist across reboots may be required. But why would we want to impose
this requirement on everyone by making it a MUST.  It's fine to make it
a MAY.  Not everyone may want to have a common handler.  It's not clear
why this is a hard requirement.

[Richard] The configuration function is important to CAPWAP MIB drafts
(including
IEEE MIB). For the configuration management, interfaces (ifIndex) is quite
important objects to configure.
If we use MAY, although some MIB object still work well, while we lost an
important function: the configuration management, especially to the
interfaces.
Another thing, to reuse the 802.11, 802.16 such MIB standards is a highlight
of the CAPWAP MIB, for it, we have to use the ifIndex as a common handler.
In summary, I am Ok with MAY, while I worry about we would lost an important
function: the configuration management, especially to the interfaces.
If it is ok to WG, I am OK with MAY :)

Thanks,

Richard

From: Richard [mailto:[email-masked]] 
Sent: 2009-06-22 19:10
To: [email-masked]; Abhijit Choudhury (achoudhu)
Cc: Yong Zhang
Subject: The issue of WTP Id

Hi, Abhijit:

I also discussed the issue 1 (The issue of WTP Id) raised by you with my
co-editor Yong.

Please check the following opinion:

If we use the Base MAC Address in 4.6.40 WTP Board Data, this 4 - Base
MAC Address is not a MUST HAVE Board Data Sub-Element.

If we use the base Bssid in 6.23. IEEE 802.11 WTP Radio Configuration,
the capwap protocol allow this to be changed by AC. ( 5.8 Configuration
Status Response Message and 5.9. Configuration Update Request Message
can have 6.23. IEEE 802.11 WTP Radio Configuration). we think here we
should use something not changeable, right?

Could we use the Vendor Identifier + serial number?

Regards

Richard

2009/6/22 <[email-masked]>

Send Capwap mailing list submissions to
       [email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
       http://lists.frascone.com/mailman/listinfo/capwap
or, via email, send a message with subject or body 'help' to
       [email-masked]

You can reach the person managing the list at
       [email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Capwap digest..."

Today's Topics:

  1. Thanks Abhijit's comment, please check my comments inline
     (Richard)

----------------------------------------------------------------------

Message: 1
Date: Mon, 22 Jun 2009 08:56:00 +0800
From: Richard <[email-masked]>
Subject: [Capwap] Thanks Abhijit's comment, please check my comments
       inline
To: [email-masked]
Message-ID:
       <[email-masked]>
Content-Type: text/plain; charset="iso-8859-1"

Hi,  Abhijit:

Thanks you. I am a editor of MIB draft. Please check my comments inline.
(identified by [Richard].

1) Q1
 Section 5.7.  WTP Profile
 In a centralized WLAN architecture, a WTP profile is used to make
 configurations such as static IP address for a WTP before and after
 it connects to the AC.  It MUST contain the serial number [RFC5415
<http://tools.ietf.org/html/rfc5415> ]
 of the WTP because the CAPWAP message received from the WTP contains
 its serial number and the AC uses this serial number to find the
 corresponding WTP profile.

[Abhijit] A serial number is not guaranteed to be unique. This needs to
be based on something that is guaranteed to be unique - like the
AP MAC address.  Need corresponding changes in the rest of the doc
where serial number is  is used like CapwapBaseWtpIdTC etc.

[ Richard ] Suggest WG decide to use the AP MAC or serial number.
 Although editors think that serial number is ok, editors could do
changes
 if most people suggest to use the AP MAC.

 2) Q2
 Another important function of WTP profile is to trigger the creation
 of WTP Virtual Radio Interfaces on the AC.  To implement this
 function, a WTP profile MUST include the WTP's model number
 [RFC5415 <http://tools.ietf.org/html/rfc5415> ], which reflects the
number of PHY radios on the WTP.  In
 this way, the creation of a WTP profile triggers the AC to
 automatically create the same number of WTP Virtual Radio Interfaces
 corresponding to the WTP's PHY radios without manual intervention.
 With the ifIndexes of WTP Virtual Radio Interfaces, the operator
 could configure and manage the WTP's PHY radios through the wireless
 binding MIB modules.

[Abhijit] In CAPWAP, WTP informs the number of radio's and creates the
profile. So, instead of assuming number of radios based on Model number,
we
should use that information.
 In fact, a model number is not indicative of how many radios are
active.  For example, a modular AP could initially start with one radio,
and then have another added later - but would be still using the same
model
number.

[Richard] The model number indicate how many radios a WTP could have and
 it is  the maximum number of radios.
When the vendors manufacture the AP equipments, the model number
already decide how many radios a specific AP could have.
Although WTP would inform the number of radio in use, the number should
be
less than the maximum number decided by the model number.
If it is required, the drafts could add some text to handle the case
when radio in use is less than the maximum radios number told by
the model number.

3) Q3

 Section 7.2.  Relationship to IF-MIB Module
 Also, as an ifIndex [RFC2863 <http://tools.ietf.org/html/rfc2863> ]
 is used as a common handler for a
 corresponding interfaces in the CAPWAP-BASE-MIB and specific wireless
 technologies MIB modules, the AC MUST have a mechanism that
 preserves the values of the ifIndexes in the ifTable at AC reboot.

[Abhijit] This seems to be a very stringent requirement to impose.
Why do the ifIndexes need to be persistent across AC reboots ?

[ Richard]  It was ever discussed during last IETF 74 meeting
and had a conclusion at the time: The WG thinks that the mechanism
brought forward by the editors is accepable.
I would like send a the slide for the last meeting to Abhijit,
and it explains a mechanism about persistence of the ifIndex.

Regards
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.frascone.com/pipermail/capwap/attachments/20090622/18283a41
/attachment.htm

------------------------------

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

End of Capwap Digest, Vol 43, Issue 4
*************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.frascone.com/pipermail/capwap/attachments/20090624/e389f29d/att
achment.htm 

------------------------------

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

End of Capwap Digest, Vol 43, Issue 6
*************************************

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 25 Jun 2009 07:39:21 +0200

> -----Original Message-----
> From: young [mailto:[email-masked]] 
> Sent: Thursday, June 25, 2009 7:01 AM
> To: [email-masked]

> [Abhijit] I went through the slides you sent. I see that IF 
> there is a desire to have a common handler, having the 
> ifIndex persist across reboots may be required. But why would 
> we want to impose this requirement on everyone by making it a 
> MUST.  It's fine to make it a MAY.  Not everyone may want to 
> have a common handler.  It's not clear why this is a hard requirement.
> 
> [Richard] The configuration function is important to CAPWAP 
> MIB drafts (including IEEE MIB). For the configuration 
> management, interfaces (ifIndex) is quite important objects 
> to configure.
> If we use MAY, although some MIB object still work well, 
> while we lost an important function: the configuration 
> management, especially to the interfaces.
> Another thing, to reuse the 802.11, 802.16 such MIB standards 
> is a highlight of the CAPWAP MIB, for it, we have to use the 
> ifIndex as a common handler.

MAY does not make too much sense. Using ifIndex as a the common handler
(and hence requiring it to be persistent across reboots) is one solution
to the requirement of correlating between the ifTable and the specific
interfaces that may be configured and monitored using other MIB tables
or even technology specific modules. If the management station cannot
rely on this common handler it has no way of making sure it configures
the right interface, or retrieves information from the right interface.

If the Working Group decides to drop the requirement of pointing from
the CAPWAP MIB to configuration operations or to 802.11 MIB information,
there is no need to keep the common handler persistent. It looks to me
however that the handler if supported MUST be persistent. 

Dan
(speaking as contributor and MIB advisor)
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

---

From: "David Harrington" <[email-masked]>
Date: Thu, 25 Jun 2009 01:59:08 -0400

Hi,

On issue#3, the WG should make a decision, so an NMS can know
definitively what to expect.
Either the ifIIndex MUST be persistent, OR
an alternative aproach MUST be persistent, OR
an NMS MUST NOT expect the interface identification to be persistent.

An NMS is likely to maintain a database of information that is keyed
based on the ifindex.

Many NMSes provide value-add by monitoring the behavior of a monitored
component over time. For example, if the rate of errors begins to
increase over time, an NMS application can predict that a problem is
likely to occur in the near future, and warn an operator. If the data
sets maintained by an NMS cannot be associated with the same interface
after a reboot, then if a reboot is detected, the NMS either operates
with data that might be assigned to the wrong interface, or, to be
safe, it must throw away any historical data related to the interface,
and the system loses its predictive ability.

If the NMS expects ifindex to be persistent, and it is not, then the
NMS could associate the wrong set of data with the ifIndex, and this
could cause lots of problems, because the NMS might alert operators
with "false posiitve" reports of configuration changes which would
totally waste an operator's time, and might mislead the operator or
the NMS application to respond in ways that could cause
misconfiguration problems, destabilizing the network.

If the ifIndex is allowed to change during a reboot, then the NMS
should have a way to determine which set of data should be associated
with which ifIndex after a reboot.  The ifAlias object was developed
expicitly to help resolve this non-determinism problem, because
requiring a persistent ifIndex can be difficult in some devices.
Unfortunately, ifAlias is not a reliable approach since it must be set
by the manager, and it MAY be not set, But it is the best alternative
to persistent ifIndexes.

>From RFC 2863:
the ifAlias name is non-volatile, and
   thus an interface must retain its assigned ifAlias value across
   reboots, even if an agent chooses a new ifIndex value for the
   interface.

Making the persistence of interface identification non-deterministic
by saying that an agent MAY or MAY NOT keep persistent ifIndexes is a
bad, bad, bad idea!!!!

David Harrington
MIB Doctor directorate
[email-masked]

> Sent: Thursday, June 25, 2009 12:01 AM
> To: [email-masked]
> Subject: [Capwap] The discussion of WTP Id issues and so on
> 
> 
> Hi，Abhijit：
> 
> Thanks.

> while we lost an
> is a highlight

---

From: young <[email-masked]>
Date: Thu, 25 Jun 2009 14:29:05 +0800

Hi, 

Thanks Dan and David's comments.
I suggest and fully support to use MUST instead of MAY.

Regards
Richard

-----邮件原件-----
发件人: Romascanu, Dan (Dan) [mailto:[email-masked]] 
发送时间: 2009年6月25日 13:39
收件人: young; [email-masked]
主题: RE: [Capwap] The discussion of WTP Id issues and so on

Dan