Bing Thanks for your reply. And I read 03 latest revision again. I understood. The draft provides two function. -Provisioning: similar with IP TunnelMIB. -Statics: count of each of CE traffic
As you mentions,I felt statics from CE is not so difficult. But I have never seen similar implementation even though it is CLI. Indeed,the statics which will be provide by this mib is NOT state of tunnel. I would like to hear wg opinion. I think it is not need "mapTunnelStatus", because we can not find Status of each of CE. BTW, this MIB not mentions relationship with NAT-MIB. Especially MAP-E CE uses A+P technology,and latest nat mib defines A+P as new feature. http://tools.ietf.org/html/draft-ietf-behave-nat-mib I'm not sure whether the draft should write relationship with NAT-MIB. And NAT-MIB does not be directly effect to this draft. But MAP-E CE is using A+P, so we should check it. Regards, -Shishio (2013/03/05 11:11), Liubing (Leo) wrote: > 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
