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? And I don't know why this oid needs for MAP-E. mapStatisticConnections mapStatisticSpecificIP mapTunnelNumAlarm mapBRPortUsageOfSpecificIpAlarm Some static could be provided by usig IP-MIB(RFC4293) and IP-FORWARD-MIB(RFC4292). 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. 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
