Subject: [Capwap] Text about a mechanism that preserves the values of ifIndex

From: young <[email-masked]>
Date: Thu, 12 Feb 2009 10:39:26 +0800

Hi, 

According to the following discussion on T4, I have the following text about
it.
1)  Yes, there are mechanisms that preserves the values of ifIndex in the
ifTable at AC reboot. 
2) I do confirm some vendors support to preserves the values of ifIndex. The
mechanisms would depend on vendor's proprietary method.
3) Here I give one method they usually use.
It is common for most vendors: The device have configuration file to keep
configuration, and interface name, device name and so on are in it. The
value of ifIndex for an interface is not in the configuration file. 
The proprietary method is:
Besides configuration file, system would have another file (suppose we call
it as interface file) to keep ifIndex value for a specific interface which
is identified by interface name. When user execute save configuration file
command, system would also save mapping relationship between interface name
and ifIndex.

During system's initiation process, it would get initial value from
configuration file. System could get interface name for a specific
interface, also it would 
Query information kept in the interface file, and get ifIndex for a specific
interface. 
By this way, ifIndex for a specific interface would keep same even after
device reboot. 

Regards
Richard

> T4. In order for ifIndex to be used as a common handler for 
> the CAPWAP MIB and for the interface specific MIB modules 
> like a dot11 MIB from IEEE one needs to ensure that the same 
> numbering scheme and mapping is used by all MIB modules, and 
> that it behaves identically for events like interface card 
> swapping, reset or power loss. I do not see how this can 
> happen, I am not sure that this is possible at all, and in 
> any case there is no text in the CAPWAP MIB that explains 
> this mechanism.
> -----------------------------------------------------------------
> Yes, when we use logic interface (such as Wireless Virtual 
> Interface) mechanism, it would have a risk to have this issue 
> when AC reboot. It is not only for fit AP, but could have for 
> other device such as switch, router.
> The device should have some methods to ensure ifIndex for an 
> interface keep same after device reboot.
> Some general rule or mechanism should be defined, while it is 
> better to make it out of CAPWAP MIB drafts as it is a general issue.

I am not sure that I understand your answer. Do you mean that you assume
that there is a mechanism that preserves the values of ifIndex in the
ifTable at AC reboot (and other events like cards swapping) but this
mechanism is out of the scope of this document or any CAPWAP document
actually? 

I would like to see a suggestion for such text, so that I can judge if
it is acceptable.

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 
发送时间: 2009年2月9日 19:16
收件人: [email-masked]
主题: Capwap Digest, Vol 39, Issue 3

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. Re: Some question on Base MIB comments (Romascanu, Dan (Dan))

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

Message: 1
Date: Sun, 8 Feb 2009 14:58:17 +0100
From: "Romascanu, Dan (Dan)" <[email-masked]>
Subject: Re: [Capwap] Some question on Base MIB comments
To: "young" <[email-masked]>,	<[email-masked]>
Cc: Yong Zhang <[email-masked]>, [email-masked]
Message-ID:
	
<[email-masked]>
	
Content-Type: text/plain;	charset="US-ASCII"

See in-line. 

Regards,

Dan

> -----Original Message-----
> From: young [mailto:[email-masked]] 
> Sent: Friday, February 06, 2009 5:20 AM
> To: [email-masked]
> Cc: [email-masked]; Yong Zhang
> Subject: [Capwap] Some question on Base MIB comments
> 
> Hi, Thanks Dan's comments. 
> 
> Most comments are quite clear.
> Parts of them we have not got point, and some of them 
> requires more discussion in the mailing list. After 
> discussion for open issues is over, we could send out 
> modification in details for each comment. If the modification 
> is ok, we would publish new version after it.
> 
> Regards
> Richard
> 
> Here is some question we have for Base MIB:
> 
> T4. In order for ifIndex to be used as a common handler for 
> the CAPWAP MIB and for the interface specific MIB modules 
> like a dot11 MIB from IEEE one needs to ensure that the same 
> numbering scheme and mapping is used by all MIB modules, and 
> that it behaves identically for events like interface card 
> swapping, reset or power loss. I do not see how this can 
> happen, I am not sure that this is possible at all, and in 
> any case there is no text in the CAPWAP MIB that explains 
> this mechanism.
> -----------------------------------------------------------------
> Yes, when we use logic interface (such as Wireless Virtual 
> Interface) mechanism, it would have a risk to have this issue 
> when AC reboot. It is not only for fit AP, but could have for 
> other device such as switch, router.
> The device should have some methods to ensure ifIndex for an 
> interface keep same after device reboot.
> Some general rule or mechanism should be defined, while it is 
> better to make it out of CAPWAP MIB drafts as it is a general issue.

I am not sure that I understand your answer. Do you mean that you assume
that there is a mechanism that preserves the values of ifIndex in the
ifTable at AC reboot (and other events like cards swapping) but this
mechanism is out of the scope of this document or any CAPWAP document
actually? 

I would like to see a suggestion for such text, so that I can judge if
it is acceptable. 

> 
> T9. What is the Vendor Identifier mentioned in Section 9 as 
> being assigned by IANA? Is this something specific for this 
> MIB document - in this case it needs to be mentioned in the 
> IANA considerations section?
> -----------------------------------------------------------------
> Yes, current description would lead to misunderstanding. 
> It should say:
>    Vendor Identifier:   A 32-bit value containing the IANA 
> assigned "SMI
>       Network Management Private Enterprise Codes"
> Whether is it ok?  

Yes. 
    
>       
> T10. Why does one need a special TC for CapwapBaseWtpIdTC? If 
> this is typically a serial number, then SnmpAdminString SIZE 
> (1..128) should do.
> -----------------------------------------------------------------
> Station, radio, WTP are main objects under management by MIB drafts.
> They would appear in the serval table and notification. 
> Suggest to have a TC for them.
> Refer to entPhysicalSerialNum in RFC4133 and Dan's comment, 
> define CapwapBaseWtpIdTC with SnmpAdminString (SIZE (0..32))

OK. 

> 
> T14 - the name of capwapBaseDataChannelSecOptions should 
> better be something that includes DTLSPolicy to make clear to 
> what fields in the AC Descriptor it corresponds. The 
> DESCRIPTION should also be consistent with the text in the 
> protocol document
> -----------------------------------------------------------------
> Ok, change capwapBaseDataChannelSecOptions with 
> capwapBaseDataChannelDTLSPolicyOptions.
> Change capwapBaseDataChannelSecConfig with 
> capwapBaseDataChannelDTLSPolicyConfig
> Also, the DESCRIPTION should also be consistent with the text 
> in the protocol document Whether is it ok?

OK. 

> 
> T17 - Object names in capwapBaseWtpStateTable do not respect 
> the naming conditions relative to capwapBaseWtpStateEntry
> -----------------------------------------------------------------
> Whether it means that it should use capwapBaseWtpState as 
> prefix for each object under capwapBaseWtpStateTable.
> If this way, I thought capwapBaseWtpId look better and 
> meaningful than capwapBaseWtpStateId. Here Id looks tight up 
> with State not with Wtp.

Yes, the recommendation is that the prefix of tableNameEntry be the same
as for tableNameObjects. 

> 
> T22 - why does the MIB support reserved(0) for 
> capwapBaseWtpFallbackEnable. Does setting to reserved(0) by 
> the management application have any significance?
> -----------------------------------------------------------------
> For MIB, whether it could not support reserved field defined 
> by protocol?
> If it is ok, reserved(0) would be removed in the MIB.

OK. 

> 
> E8. No need to repeat the text in the DESCRIPTION clause if a 
> TC is used (e.g. capwapBaseTunnelModeOption, capwapBaseMacTypeOptions)
> -------------------------------------------------------------------
> How about we say DESCRIPTION's capwapBaseTunnelModeOption in this way?
> As per CapwapBaseTunnelModeTC's DESCRIPTION

Even this is not needed because by using the TC SYNBTAX it is implied
that the behavior of the object is the same. The DESCRIPTION clause
should refer to the functionality of the object itself. 

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

_________________________________________________________________
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 39, Issue 3
*************************************

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

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