Hi, Shishio > -----Original Message----- > From: Shishio Tsuchiya [mailto:[email protected]] > Sent: Tuesday, March 05, 2013 1:00 PM > To: Liubing (Leo) > Cc: [email protected]; [email protected]; Fuyu (Eleven) > Subject: Re: [Softwires] MAP-MIB request for comments > > 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
[Bing] We defined two subtrees. One is mapRule, which only contains the Mapping Rules; the other is mapTunnel, in fact it is quite different with IP TunnelMIB, because the "Tunnels" in MAP is only an implicit correlation between a certain BR and CEs, no entries there to record the tunnel itself. So we just define some static information to present the implicit "Tunnels". With current definition, we couldn't count per CE traffic in BR, only the total MAP traffic. Because we thought it might be too complex to maintain a counter for each CE address in BR. If we really care about per CE traffic, we can get it on CE by mapTunnel subtree. (I realized the mapTunnel definition was only in BR perspective in this draft, we'll modify it later.) > > 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. [Bing] Thanks, we'll consider it in the next version. > > 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. [Bing] Thanks for the information. I've had a quick review, but I think it's better NOT to include it in MAP-MIB, if we need those information, we can implement the latest NAT-MIB in the CE. We treated the NAT-MIB as a separated common building block in MAP system, we thought it was better NOT to mix them together. Best regards, Bing > 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
