Subject: Re: [Softwires] MAP-MIB request for comments

From: Shishio Tsuchiya <[email-masked]>
Date: Tue, 05 Mar 2013 02:08:53 +0900

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-masked]]
>> Sent: Thursday, February 07, 2013 8:49 PM
>> To: Liubing (Leo)
>> Cc: Softwires WG; [email-masked]; 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-masked]
> https://www.ietf.org/mailman/listinfo/softwires
> .
> 

.

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 5 Mar 2013 02:11:48 +0000

Hi, Shishio

Thanks for your review. Please see inline.

> From: Shishio Tsuchiya [mailto:[email-masked]]
> Sent: Tuesday, March 05, 2013 1:09 AM
> To: Liubing (Leo)
> Cc: [email-masked]; [email-masked]

[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.

> 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

[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.

[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

> > 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
> >

---

From: Shishio Tsuchiya <[email-masked]>
Date: Tue, 05 Mar 2013 14:00:20 +0900

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

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 5 Mar 2013 06:56:31 +0000

Hi, Shishio

> Sent: Tuesday, March 05, 2013 1:00 PM
> To: Liubing (Leo)
> Cc: [email-masked]; [email-masked]; Fuyu (Eleven)

[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.)

> I think it is not need "mapTunnelStatus",  because we can not find Status of

[Bing] Thanks, we'll consider it in the next version.

> 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

> > [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.
> >
> > [Bing] mapStatisticConnections & mapStatisticSpecificIP are just explained
> as abovementioned. But the latter two should be removed in this version,
> thanks for finding the bugs.
> >
> > [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.
> >
> >>>> draft would make the BR recording every CEs' addresses connected to
> it.
> >> This
> >>>> but it is far from the weight of "stateful", because the the BR tunnel
> table
> >> is
> >>>> 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