Hi, Shishio Thanks for your review. Please see inline.
> -----Original Message----- > From: Shishio Tsuchiya [mailto:[email protected]] > Sent: Tuesday, March 05, 2013 1:09 AM > To: Liubing (Leo) > Cc: [email protected]; [email protected] > Subject: Re: [Softwires] MAP-MIB request for comments > > Bing > I agree ISP would like to know status of MAP deployment/usage sometimes. > But I can not agree that MIB provides this function. > > I think this MIB targets provisioning/monitoring for CE/BR. > If so ,is it enough to check MIB object of CE ISP to know MAP deployment? [Bing] It is enough for knowing whether MAP is deployed or not. But if we want know more detailed information, e.g. how many CEs have been connected to a certain BR in a period, we need to do it with MAP-specific MIB, because MAP itself is stateless, there's no entries of the MAP "tunnels" exist in CE/BR, we need the CE/BR to provide the information when it does MAP encapsulation/de-encapsulation. Considering some ISPs might not have strong requirement of these kind of detailed statistic information, we made the MAP-MIB compliance as two levels, one is basic which only contains MAP rules, the other is full-function containing both rules and statistic information. > And I don't know why this oid needs for MAP-E. > mapStatisticConnections > mapStatisticSpecificIP > mapTunnelNumAlarm > mapBRPortUsageOfSpecificIpAlarm [Bing] mapStatisticConnections & mapStatisticSpecificIP are just explained as abovementioned. But the latter two should be removed in this version, thanks for finding the bugs. > Some static could be provided by usig IP-MIB(RFC4293) and > IP-FORWARD-MIB(RFC4292). [Bing] They can provide some common static, but MAP-specific static, as mentioned above, could not be provided by them, because they could not identify which packets are MAP and which are just normal IPv6 packets. > But we may need new object for MAP-E security check statics because > MAP-E checks consistency of IPv4/IPv6 src address. > Because most of vendors already supports security mechanism,and they has > static counter for inconsistency of packet. > http://tools.ietf.org/html/draft-janog-softwire-report-01#section-2.2 > The counter would be new object for MAP/6rd. [Bing] I think it is a good point worth to be considered. And I'd like to hear others' comments on this. Thank you. Best regards, Bing > If it is needed,I will let's add our 6rd mib also. > > Regards, > -Shishio > > > > > > (2013/02/08 15:56), Liubing (Leo) wrote: > > Hi, Ole > > > > Thanks for your quick reply. > > > > In order to do the statistics, the BR need a bit more codes to extract the > > CE > IPv6 addresses when doing de-encapsulation. > > That is what we said in the last mail the operation might slightly impact > > the > performance, so we defined this MIB function as optional. > > > > All the best, > > Bing > > > >> -----Original Message----- > >> From: Ole Troan [mailto:[email protected]] > >> Sent: Thursday, February 07, 2013 8:49 PM > >> To: Liubing (Leo) > >> Cc: Softwires WG; [email protected]; Yong Cui > >> Subject: Re: [Softwires] MAP-MIB request for comments > >> > >>> The MAP-MIB draft has been updated as -03 version. > >>> > >>> In IETF85@Atlanta, we had a brief discussion, and the main comment > was > >> from Mark Townsley. He pointed out that the tunnel table defined in the > >> draft would make the BR recording every CEs' addresses connected to it. > This > >> operation would somewhat counterbalance the benefit of stateless > design. > >>> Basically, Mark's comment is a real issue, but not that serious. The > tunnel > >> table needs the translation/encapsulation application to provide CE > address > >> to the MIB agent, that might slightly impact the forwarding performance, > >> but it is far from the weight of "stateful", because the the BR tunnel > >> table > is > >> not for real-time look up, it is just a kind of logging. In the worst > >> situation, > >> even the MIB crash, the packet forwarding won't be bothered. > >>> > >>> The purpose we defined a tunnel table is to add some statistics of CE > >> connecting BR. For example, the ISP might want to know how many/what > >> CEs had been connected to a certain BR. This might be useful for service > >> analysis and management, e.g. to static percentage of MAP enabled and > the > >> traffic, so that the ISP could learn the status of MAP deployment/usage, > then > >> might make some policies. > >>> Considering the tunnel table might still more or less bring some > additional > >> complexity, we defined it as an optional object in the MIB. We defined > two > >> map-MIB-Compliance, one is basic compliance only containing the rule > table, > >> the other is full compliance containing rule table and tunnel table. > >> > >> how is the BR supposed to learn the CE addresses? > >> > >> cheers, > >> Ole > > _______________________________________________ > > Softwires mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/softwires > > . > > > > . _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
